project-tiny-context-harness 0.11.0 → 0.12.0

package/assets/skills/context_product_plan/SKILL.md

@@ -1,42 +0,0 @@
----
-name: context_product_plan
-description: Use when the user explicitly asks for a product plan/spec, product-manager analysis, requirements, goals/scope, business rules, user stories/flows, acceptance criteria, 产品方案, 需求方案, 功能方案, 业务规则方案, 用户流程, 用户故事, or 验收标准 in a Minimal Context Harness project. Do not trigger for ordinary coding, debugging, package/release work, visual design/resource generation, or a request whose durable question is only Product Surface responsibility.
----
-
-# Context Product Plan
-
-## Ownership
-
-Own product meaning: goals, users, problem, scope/non-goals, business and user-visible rules, user flows, product feedback, success/acceptance meaning and genuine product decisions. This Skill does not own Product Surface placement, visual Design Authority, generated design resources, technical architecture, implementation, verification authority or a Gate.
-
-Project-specific product behavior belongs in `project_context/**` and may be specialized by `<harnessRoot>/skills/product_plan/SKILL.md`. Durable conclusions never live only in the Skill output.
-
-When Long-Task is active, it alone owns Source/Contract lifecycle and Final Gate. This Skill may clarify product meaning for the existing Source/Context, but creates no second plan, requirement ledger, stage or acceptance path.
-
-## Workflow
-
-1. Read `project_context/global.md`, `project_context/context.toml`, the default area and product owners triggered by the request. Use the default Workflow Contract's bounded high-signal Context search before `Context Delta`.
-2. Establish target users/actors, problem and desired outcome, scope/non-goals, relevant objects/capabilities, main flow and material alternatives, business/user rules, failure/degraded/recovery expectations, success signals and real decision gaps.
-3. Treat explicit user/product/legal/security/commercial/external constraints as Source. Internally classify each material constraint as Context-covered, requiring Context update, task-local, out of scope or decision-required. Current code reveals implementation; it cannot silently redefine product intent.
-4. Keep conditions and acceptance concrete enough to be observed through the actual product entry. A representative sample cannot satisfy a declared full-population/all-provider/all-interface/all-platform outcome; unresolved scope is decision-required.
-5. Route durable information/action/feedback placement, main-versus-drilldown responsibility, screen ownership or cross-surface IA to `context_surface_contract`. Provide goals, users, flows, rules and acceptance meaning as inputs; do not compile a Surface Contract here.
-6. Route durable visual identity/tokens/rationale/adopted-target interpretation to `context_uiux_design`; new resource generation to `design-resource-authoring`; architecture/engineering design to `context_development_engineer`.
-7. Decide exactly one `Context Delta: none|required`. Update the smallest product owner before implementation when goals, scope, business/user rules, flow ownership, acceptance semantics or durable rationale change. Local bugs or implementation drift that preserve meaning are `none`.
-8. Under the default Workflow Contract, hand implementation to the current Goal and include product conformance in its one current-candidate Contract Conformance. Under Long-Task, project exact non-UI meaning from this product owner into its existing Source/Contract mechanism only—never build a nested Fact ledger or second closure.
-
-## Product-plan output
-
-Keep the result concise and implementation-usable:
-
-- goal, user/problem and success outcome;
-- in-scope and non-goals;
-- product objects/capabilities and owner;
-- main and material degraded/recovery flows;
-- business/user-visible rules and product feedback;
-- acceptance boundaries and observation entry;
-- assumptions, external constraints and decision-required gaps;
-- durable Context changes and downstream owner routes.
-
-Do not invent missing business, legal, security, commercial or external decisions. Do not create a required PRD, `plan.md`, Task Contract, Source-to-Context table, matrix, evidence ledger, phase or lifecycle. Context may name repeatable validation/deployment entries but never say a test or deployment passed unless current evidence establishes it.
-
-Finish with `Context: updated ...` or `Context: no durable fact change`, and clearly separate judged, verified, unverified and decision-required scope.

package/assets/skills/context_surface_contract/SKILL.md

@@ -1,205 +0,0 @@
----
-name: context_surface_contract
-description: Use when the user asks for Product Surface Contract, Surface Contract, Screen Contract, durable product-surface responsibility, information/action/feedback ownership, information architecture governance, main/drilldown ownership, UI product boundary, 产品界面职责治理, 产品接触面, 用户接触面, 页面职责契约, 界面责任契约, or 主层/下钻归属 in a Minimal Context Harness project. Do not trigger for ordinary CSS/UI fixes, product-goal planning, visual Design Authority, design-resource generation, or implementation-only work unless durable surface responsibility is explicitly being defined or repaired.
----
-
-# Context Surface Contract
-
-## Package-Managed Boundary
-
-This Skill is generated by `ty-context sync` and owned by the Harness package. Do not edit the generated `context_surface_contract` Skill directly.
-
-Project-specific Product Surface responsibilities belong in `project_context/**` and an optional `<harnessRoot>/skills/surface_contract/SKILL.md`. This is the sole package-managed owner for durable surface responsibility; it must not contain business-specific page duties, provider facts, project names, raw payload schemas or product examples.
-
-## Purpose
-
-Help agents turn broad product/UI principles into concrete, project-owned Product Surface Contracts while keeping Minimal Context small.
-
-This Skill owns where user-facing information, actions and feedback belong, including main/drilldown/diagnostic/detail responsibility and cross-surface ownership. `context_product_plan` owns goals, users, business rules, flows and acceptance meaning; `context_uiux_design` owns Design Authority/tokens/rationale/adopted-target interpretation; `design-resource-authoring` owns resource generation. This Skill owns none of those, performs no implementation acceptance and creates no Gate.
-
-A Product Surface is any user-facing interface where users make judgments, take actions and receive feedback. Covered platforms include Web apps, dashboards, admin or operations UI, mobile screens, desktop windows, game UI/HUD/menu scenes, CLI/TUI output, browser extension or plugin UI, and embedded, kiosk or device UI.
-
-Use two depths without creating new roles: Product Surface Contract for cross-surface/main-versus-drilldown ownership, and an optional on-demand Screen Contract when one screen needs stable entry/exit/shared-state, information hierarchy, layout regions, navigation, variants or material-control semantics. Start from managed `product-surface-contract.md` or `screen-contract.md`; do not require both for every task.
-
-## Context Roles
-
-Do not add a new `context_role`.
-
-Use existing roles:
-
-- `contract` for cross-surface, cross-area or project-level Product Surface Contracts.
-- `area` or `subdomain` for owning product-domain Screen Contracts.
-- `verification` for repeatable UI, CLI, app or product-surface validation paths.
-- `decision-rationale` for stable product-surface tradeoff reasons.
-- `implementation-index` for code navigation only.
-
-Forbidden roles include `surface-contract`, `product-surface`, `web-contract`, `app-contract` and `game-surface`.
-
-Use `DESIGN.md` only for visual identity, visual tokens and visual rationale. Do not put surface responsibility, main/drilldown ownership or diagnostic placement into `DESIGN.md`.
-
-Keep one meaning owner: Surface Context owns cross-surface responsibility, Screen/interaction Context owns durable screen/control behavior, `DESIGN.md` owns visual-system semantics and target interpretations, authored targets own concrete declared composition, and verification Context owns repeatable proof paths. Link them with stable surface/control/target keys instead of copying facts.
-
-## Mode Selection
-
-Use the narrowest mode that matches the request:
-
-- Audit Mode: inspect whether existing surfaces have clear responsibility.
-- Compile Mode: turn audit findings or user decisions into Context candidates.
-- Apply Mode: write durable Context only when the user explicitly allows durable writes, or when already-authorized product/UI implementation independently yields `Context Delta: required` in the current Goal.
-- Conformance Mode: check implementation against an existing Product Surface Contract.
-
-Do not run implementation, long validation, browser smoke, app smoke or CLI smoke unless the user explicitly asks for execution.
-
-## Audit Mode
-
-Use when the user asks to inspect, review or audit surface responsibility.
-
-Output only:
-
-- Surface list.
-- Surface platform.
-- Code, screenshot, CLI or app evidence inspected.
-- Existing Context expectation.
-- Drift, missing contract or backend complexity exposure.
-- Candidate `Context Delta`.
-- Suggested durable placement.
-- Optional temporary audit path under `tmp/**` when useful.
-
-Do not edit durable Context by default. Code, screenshots and CLI output are evidence of current implementation, not authority for product responsibility.
-
-## Compile Mode
-
-Use when turning audit findings or user decisions into Context candidates.
-
-Output:
-
-- Project-level Product Surface Contract candidate when responsibilities cross surfaces or areas.
-- Area-level Screen Contract candidate when ownership belongs inside one domain.
-- `context.toml` candidate registration with `role = "contract"` when durable registration is needed.
-- `global.md#Context Index` candidate entry when a new Context file is added.
-- Verification candidate for repeatable surface checks.
-- Internal source classification when an external product, architecture, technical or acceptance source changes durable surface responsibility; do not create a Markdown coverage table.
-- Repo-local Skill task-block candidate when the user wants project-specific enforcement.
-
-Do not assume business responsibilities from current code shape alone. Ask for confirmation if the candidate would silently choose between competing product or information-architecture meanings.
-
-## Apply Mode
-
-Use only when the user explicitly allows durable writes, or when product/UI implementation is already authorized and the current Goal independently decides that durable Surface/Screen responsibility changed. Skill activation, analysis, audit, candidate comparison or resource generation alone never grants write authority.
-
-Allowed writes:
-
-- `project_context/**`.
-- `project_context/context.toml`.
-- `project_context/global.md#Context Index`.
-- Optional `verification` role Context.
-- Optional separate project-local Skill files when the user explicitly wants project-local enforcement.
-
-Forbidden writes:
-
-- Package-managed generated Skills in a consumer project.
-- `<harnessRoot>/ty-context-managed/**` in a consumer project.
-- Business code unless the user also requested implementation.
-- Generated files.
-- `DESIGN.md`, except visual tokens or visual rationale that do not belong in a Product Surface Contract.
-
-If `Surface Contract Hit` is `none` and the task creates durable surface responsibility, set `Context Delta: required` and update project Context before implementation alignment.
-
-## Conformance Mode
-
-Use after implementation or during review.
-
-Output:
-
-- Surface Contract Conformance.
-- External-source constraint classification and implementation alignment status.
-- Remaining Drift.
-- Missing Context.
-- Implementation Drift.
-- Verification run / not_run / failed.
-
-Do not store one-off evidence, screenshots, logs, raw outputs or implementation summaries in Context.
-
-## Compiler Questions
-
-For each touched surface, answer only what is relevant:
-
-- What surface is being touched?
-- What platform shape does it have?
-- Which authoritative target-user and usage-context reference applies?
-- What primary user question does it answer?
-- What primary task outcome, primary work object and shortest task loop does it support?
-- Which critical context must remain visible while the user acts?
-- How are each material operation, affected object and feedback related?
-- Does the task force repeated scrolling, navigation or context switching to make one judgment?
-- Which client/host, input-method and size-class constraints change the interaction topology?
-- What belongs on the main surface?
-- What must move to drilldown, diagnostics, operations, evidence or technical detail?
-- Which long-running or mutating actions require task id, progress, retry, import, recovery or history?
-- Which empty, loading, stale, unavailable, fixture or fallback states matter?
-- What validation path can prove conformance?
-- If this came from an external plan/source, which source constraints are covered by existing Context, require new Context, are task-local only, are explicitly out of scope, need user decision or remain under-scoped?
-
-When screen depth is material, also answer only the applicable questions:
-
-- What stable surface/route key, entry context, exit outcome, inherited state and committed state identify the screen?
-- What is the semantic information order and which regions are fixed, scrolling or overlay-owned?
-- Across supported size classes, which regions remain, reflow, collapse, become sheets/sidebars/modals or move to another surface, and how is the primary work object preserved?
-- Which navigation, back/cancel, focus restoration, interruption and responsive/mode/state variants are durable?
-- For each material stable control key, what are its region/location, type/label, user task, visibility/availability, trigger/input/validation/default, interaction/navigation, loading/empty/success/failure/recovery/permission/feedback and accessibility semantics?
-- Which exact-target/constraint/inspiration IDs govern which declared conditions, and which verification path proves each independent claim?
-
-Before applying material UI facts, perform UI Authority Closure: classify each item as Context-covered, Context update, task-local, out of scope or decision-required. Conflicting controlling owners fail closed; current code, timestamps and Contract YAML do not silently win.
-
-## Repo-Local Task Block Candidate
-
-When the user wants project-local enforcement, propose a separate project-local Skill block like this and tailor only the project-specific answers:
-
-```markdown
-## Surface Contract Task Block
-
-For any task touching user-facing surfaces, information placement, forms, filters, search, long-running UI actions, diagnostics, evidence, CLI/TUI output or main/drilldown ownership, answer before implementation:
-
-- Surface Contract Hit: `<context file / none>`
-- Surface: `<route / screen / window / panel / command / HUD / menu>`
-- Surface Platform: `<web | mobile | desktop | game | cli-tui | extension | embedded | mixed>`
-- Owning Product Domain: `<area / subdomain>`
-- Primary User Question: `<one concrete user judgment>`
-- Primary Task Outcome / Work Object / Loop: `<outcome; object; orient-act-feedback-finish loop>`
-- Critical Context Kept Visible: `<context required while acting>`
-- Operation–Object–Feedback: `<material relationship>`
-- Client / Size-Class Topology: `<host/input constraints and region changes>`
-- Main Surface Allows: `<durable visible information and actions>`
-- Main Surface Forbids: `<backend fields, raw payloads, diagnostics, debug ids, fake states, etc.>`
-- Drilldown Ownership: `<details / evidence / operations / diagnostics / technical details>`
-- Long Task State Requirement: `<run id, progress, retry, recovery, import, history, or none>`
-- Context Delta: `<none | required>`
-- Verification: `<view-model test / component test / browser smoke / CLI smoke / manual check>`
-```
-
-Do not add this task block to package-managed default Skills as a universal gate. Projects opt in through separate project-local Skills.
-
-## Implementation Alignment
-
-When implementation is also requested, align code with the Product Surface Contract:
-
-- View-models or presenters should expose user-facing states instead of raw backend payloads when that contract exists.
-- Components or commands should render main-surface facts and move technical details to the owning drilldown.
-- Long-running actions should persist or recover the required operation state.
-- Tests should assert user-facing state semantics, not only backend field plumbing.
-- Browser, app, CLI or game smoke checks should validate actual surface behavior when feasible.
-
-Final handoff should include concise `Surface Contract Conformance`: contract source, implementation alignment, remaining drift and verification status.
-
-Conformance must internally confirm that every important external-source constraint is covered by Context, updated into Context, task-local, explicitly out of scope or awaiting a genuine user decision, and that controlling surface facts reached the correct implementation. Unresolved constraints or non-aligned surface implementation mean the work cannot be described as fully aligned; component, modal, viewmodel or unit evidence alone cannot prove main-surface ownership. Do not create a fixed `plan.md`, Task Contract file or Markdown mapping tables for this check.
-
-## Output Boundaries
-
-- Do not create PRDs, UI/UX handoff docs, ADRs, stage artifacts, lifecycle state or phase gates.
-- Do not update Context for ordinary CSS tweaks, copy edits or one-off UI bug fixes unless durable surface responsibility changes.
-- Do not treat current backend fields, enums, JSON, screenshots or terminal output as product intent.
-- Do not invent rationale; rejected alternatives or tradeoffs belong in Context only when they are stable enough to affect future surface decisions.
-- Do not add a surface-specific validator, edit-order gate, plan-contract validator or package-level mandatory Surface Contract gate.
-- Do not create a `design`/`screen` Context role, per-surface readiness state, UI/UX Contract lifecycle or required Screen Contract for local fixes.
-- Do not include business-domain examples in this package-managed Skill.
-- Do not author visual values, `DESIGN.md`, design resources, product acceptance evidence, a verification verdict or a workflow Gate.

package/assets/skills/context_uiux_design/SKILL.md

@@ -1,53 +0,0 @@
----
-name: context_uiux_design
-description: Use when the user explicitly asks to establish, adopt or repair durable UI/UX Design Authority, DESIGN.md, design-system governance, visual tokens/rationale, adopted target interpretation, UI Authority Closure, selected-design alignment or durable visual standards; or when actual task content requires material UI/UX analysis or audit for a new page/flow/complex control, information hierarchy, fixed/scroll/overlay/sheet/sidebar/modal topology, map/canvas/editor work, primary task and feedback loop, client adaptation, navigation/recovery/states or accessibility in a Minimal Context Harness project. Do not trigger merely for product/surface responsibility, design-resource generation, ordinary local UI implementation, CSS/copy/icon/image fixes, local exact-target alignment, a single-control visual preview or an unselected visual exploration.
----
-
-# Context UI/UX Design
-
-## Ownership
-
-Own durable Design Authority only: root `DESIGN.md`, visual identity and exact-value token source/generation direction, visual rationale, canonical adopted-target interpretation/selection basis, adoption records, UI Authority Closure and selected-design alignment.
-
-This Skill does not own product goals/business rules/acceptance (`context_product_plan`), information/action/feedback and main/drilldown responsibility (`context_surface_contract`), resource generation (`design-resource-authoring`), implementation, or acceptance. Route rather than duplicate those owners.
-
-Project-specific UI/UX rules may live in `<harnessRoot>/skills/uiux_design/SKILL.md`; durable facts remain in `DESIGN.md` and owning `project_context/**`. When a valid Long-Task binding is active, `long-task-workflow` alone owns Source/Contract lifecycle, formal verification, Final Gate and completion. This Skill may contribute non-authoritative task-level UI/UX analysis and Design Authority closure, but creates no second plan, lifecycle, Authority, Gate or acceptance path.
-
-## Task-level analysis adapter
-
-For a material task-analysis trigger, read [task-uiux-analysis.md](references/task-uiux-analysis.md) completely and apply only the relevant methods. This adapter is non-authoritative: Product/Surface/Screen Source owns the user, page duty, primary task/work object, information/action/feedback and interaction-topology facts; this Skill still owns durable Design Authority only. The current Goal may compare and select implementation candidates under those constraints. A conflicting candidate cannot proceed to resource generation or implementation until the stale owner is authoritatively updated or a genuine decision is obtained.
-
-## UI Authority Closure
-
-1. Read core/default and owning surface/interaction Context, root `DESIGN.md`, its authored token source/generation direction, existing production route/components and every affected selected `exact-target` or `constraint` through its immutable locator. Run `ty-context design-resource preflight <handoff.md>` before treating a formal handoff as input.
-2. Classify references as `exact-target`, `constraint` or `inspiration`. Inspiration authorizes no reproduction claim. Provider success, a hash/index or an implementation screenshot proves neither selection nor fidelity.
-3. For every affected stable surface/control/target key, classify durable meaning as Context/`DESIGN.md` covered, requiring update, task-local, out of scope or decision-required. Conflicting, missing, stale, unreadable or unselected authority fails closed for the affected claim.
-4. Confirm exactly one canonical adoption record per adopted target:
-   - project/system/component-family targets are fully owned by `DESIGN.md`;
-   - screen/interaction targets are fully owned by the owning Screen Contract, with `DESIGN.md` keeping only the stable key and owner/anchor;
-   - the record preserves interpretation, selection basis, immutable path/URI and digest, applicable conditions and editable upstream owner/locator/update route.
-5. Never overwrite an adopted baseline. Create a new immutable version/digest, review it deliberately and update the unique canonical record. An implementation render/diff is evidence and cannot become the target it claims to match.
-6. Decide exactly one `Context Delta: none|required`. Skill activation, analysis, audit or candidate comparison alone authorizes no durable write. Durable visual-system, token, rationale, adopted interpretation, owner/anchor or verification-route change is `required`; ordinary UI/CSS fixes that preserve authority are `none`. When product/UI implementation is already authorized and the current Goal independently finds a durable Surface/Screen change, update the smallest owning Surface Context before code or return `decision-required`.
-7. Route unresolved surface placement to `context_surface_contract`; route any request to generate/iterate a wireframe, prototype, visual candidate, state study or handoff to `design-resource-authoring`. Do not invoke resource generation implicitly.
-
-## Selected-design alignment
-
-For a selected implementation handoff, consume the actual canonical resource and its dependency/Fact closure; do not stop at an index or aggregate `complete` label. Preserve exact located values and design-system lineage through stable keys rather than duplicating them into Context.
-
-An `exact-target` claim requires condition-specific full-target layout and pixel comparison through a project-owned Oracle; a named constraint requires proof of that constraint only. Validate affected state, viewport/platform, theme/mode, content stress, accessibility/input and motion conditions declared by Source. Never replace declared combinations with representative/pairwise sampling unless Source narrows scope or a project-owned complete equivalence proof exists.
-
-Implementation conformance runs on the real production route/component and affected cold-start journey after the final change. Detached specimens and deep links are supplemental. Report conditions not established; resource integrity/preflight is not production conformance, and screenshot baseline replacement merely to erase a failure is forbidden.
-
-## DESIGN.md boundary
-
-Use Google `@google/design.md` compatible structure: supported YAML tokens plus Markdown rationale. Maintain Design Authority status, one authored exact-value token source/generation direction and the canonical records owned at project/system/component-family scope. Do not add unsupported front-matter keys or duplicate exact values already owned by a project-native token source.
-
-If available after a change, run `npx @google/design.md lint DESIGN.md`. Exported CSS/theme files are generated implementation outputs, not competing authored truth.
-
-Missing/unconfigured authority blocks invented style-bearing production design. Only an explicit request to initialize/generate/select/adopt the project design system routes to `design-system-authoring`; local fixes and explicit non-fidelity prototypes remain lightweight.
-
-## Output
-
-Report affected authority owners/keys, selected resource classification and condition coverage, immutable/editable provenance, closure/update decisions, implementation-alignment checks, unresolved claims and `Context: updated ...` or `Context: no durable fact change`.
-
-Do not create a UI lifecycle, resource pack, Product Surface Contract, acceptance record, fixed plan/matrix, phase or second Authority/Gate. Do not write one-time screenshots, test logs, debug notes or implementation summaries into Context/`DESIGN.md`.

package/assets/skills/context_uiux_design/references/task-uiux-analysis.md

@@ -1,82 +0,0 @@
-# Task-Level UI/UX Analysis
-
-Use this non-authoritative reference only for material UI/UX reasoning or audit. It helps the current Goal understand and compare candidates; it does not own product meaning, page duty, information/action/feedback placement, interaction topology, Design Authority, resources, implementation or acceptance. Product/Surface/Screen/Design Source remains controlling.
-
-## 1. Recover the user and operating context
-
-Read the available product and Surface/Screen Source before evaluating layout. Identify only what is authoritative or explicitly task-local:
-
-- target user or role and usage context;
-- primary task outcome and success feedback;
-- client/host/platform, input mode, viewport/size class and environmental constraints;
-- current page/surface duty and entry/exit context;
-- permissions, data/state, recovery and accessibility constraints; and
-- affected exact targets, constraints and inspirations.
-
-Do not infer a user, task priority or product rule from a feature list, screenshot or current component tree. Missing meaning that changes the candidate remains `decision-required` or belongs in the stale owning Source.
-
-## 2. Model the primary work object and task loop
-
-Name the object the user is inspecting, creating, editing, moving or deciding about. Trace the shortest meaningful loop:
-
-```text
-orient -> inspect/select the work object -> act -> see local feedback -> recover or continue -> finish
-```
-
-For each material action, keep operation, affected object and feedback spatially and temporally understandable. Record which context must remain visible while acting, what state commits, how cancellation/retry works and where focus/selection returns. Secondary diagnostics or configuration must not displace the primary work object without an explicit Surface decision.
-
-## 3. Test information hierarchy and topology
-
-Evaluate semantic priority before visual polish:
-
-- primary judgment, work object and action;
-- critical context that must remain visible;
-- supporting information and secondary actions;
-- drilldown/evidence/diagnostic ownership; and
-- loading, empty, partial, error, permission, offline and recovery states.
-
-Compare the smallest material topology candidates: fixed versus scrolling regions; inline versus overlay; sidebar, sheet, modal or popover; split view; map/canvas/editor viewport; and navigation versus contextual reveal. For each candidate, explain what remains visible, what scrolls, who owns focus/back/cancel and how the primary loop changes across size classes.
-
-Client-specific structure is allowed when host chrome, safe area, keyboard/input method, pointer/touch conventions, native navigation or viewport constraints materially differ. Do not treat a desktop layout shrunk to mobile width as mobile interaction design.
-
-## 4. Walk the task and its counterfactuals
-
-Run a concise cognitive walkthrough for the primary path and material failure/recovery path:
-
-1. Can the user identify the current work object and next useful action?
-2. Is the action discoverable and available at the moment it matters?
-3. Is the affected object unambiguous before commit?
-4. Is progress, success, failure or partial result visible near the action/object?
-5. Can the user cancel, retry, undo, navigate back or recover without losing unexplained state?
-6. Do keyboard, focus, touch target, screen-reader label/order, contrast and reduced-motion needs remain viable?
-
-Challenge the leading candidate with long content, empty/error/permission states, narrow and wide size classes, localization/text scaling, keyboard or IME display, interrupted work and returning to the prior selection. Apply only conditions material to Source; do not invent a universal matrix.
-
-## 5. Compare and select under authority
-
-For each material candidate, state:
-
-- which authoritative facts it satisfies;
-- the primary-loop advantage and cognitive cost;
-- repeated scroll, navigation or context-switch cost;
-- state/recovery/accessibility consequences;
-- client/size-class behavior; and
-- what evidence or decision would change the choice.
-
-The current Goal may select among implementation-equivalent candidates when Source delegates that freedom. If candidates change product meaning, page duty, main/drilldown placement or a durable interaction topology, update the smallest owning Product Surface/Screen Context only when writes are already authorized and `Context Delta: required`; otherwise return `decision-required`. If a candidate conflicts with an adopted exact target or Design Authority, repair/revise the owning authority first. Only then may explicit resource generation route to `design-resource-authoring`.
-
-## Failure sentinels
-
-Explicitly check for these common defects when relevant:
-
-- repeated scrolling or cross-surface switching to compare information needed for one decision;
-- a hidden, collapsed or displaced primary work object;
-- critical actions detached from the object or hidden behind unrelated navigation;
-- feedback that does not identify the operation and affected object;
-- a keyboard or IME obscuring the editable object, commit/cancel actions or validation feedback;
-- destructive, interrupted or failed work with no understandable recovery path; and
-- mobile behavior produced only by shrinking desktop regions, with no touch/navigation/keyboard adaptation.
-
-## Output
-
-Return a concise task model, authoritative inputs and gaps, primary work object/loop, operation-object-feedback relationship, hierarchy/topology candidates, walkthrough/counterfactual findings, selected candidate or decision gap, owner/Context effect and verification suggestions. Do not create a required UI plan, matrix, lifecycle, resource pack, acceptance result or durable task-level UI/UX authority.

package/assets/skills/design-resource-authoring/SKILL.md

@@ -1,63 +0,0 @@
----
-name: design-resource-authoring
-description: Use when the user explicitly asks to generate, author, commission, iterate or recover design resources; use Open Design; create a scoped wireframe, prototype, visual candidate, component/control state study or implementation handoff; or asks to 生成设计资源, 使用 Open Design, 生成原型图, 生成高保真/低保真设计, 为开发准备设计资源, 恢复设计资源任务, or 先看一个控件/页面效果 in a Minimal Context Harness project. Do not trigger for generic design discussion, UX audits, ordinary UI implementation, local CSS fixes, durable Design Authority adoption, initial product-proposal authoring or Long-Task execution.
----
-
-# Design Resource Authoring
-
-Commission the smallest sufficient resource set for the user's explicit output/development scope. “Smallest” limits artifact count and surrounding scope, never material information granularity. Open Design or another selected provider owns generation; this Skill owns task-local scoping, provider adaptation, iteration, selection reconciliation and handoff preparation—not provider prompts/runtime, Design Authority, product meaning or acceptance.
-
-## Hard boundaries
-
-- A raw proposal, plan, brief, screenshot or existing resource is valid input. Never require or create a special intermediary planning format, and never rewrite caller-owned Source except for the one explicitly selected proposal reconciliation.
-- The explicit output/development scope is a hard ceiling. Necessary surrounding context may orient the slice but cannot expand it. Report an outside-ceiling effect as existing `decision-required` with reason `scope-expansion-required`; only explicit user expansion changes the ceiling.
-- Candidates are ordinary external Source. They do not select themselves, become `exact-target`, update `DESIGN.md`/Context or prove implementation acceptance.
-- A selected task design does not update the project design system. DRA may emit only the non-authoritative Authority Delta Assessment; it never invokes Design System Authoring, selects a system candidate or adopts Authority.
-- Keep candidate effects in a task-local buffer. Only after explicit selection or explicitly delegated selection may accepted decisions be reconciled once and idempotently into the initial proposal; never write rejected/unresolved meaning as accepted.
-- Never mutate `project_context/**`, `DESIGN.md`, a Delivery Contract, production code or tests as a resource-authoring side effect.
-- Do not require a prototype, fidelity pair, provider-native file, fixed directory, variant count, resource pack or one artifact per control. Reuse selected component families and group repeated controls.
-- Visual resources may express user-visible interaction/presentation but cannot invent or become sole owner of business, data, permission or algorithmic rules.
-- A Web/App implementation resource must be feasible on the real project substrate. DRA may enumerate Source-backed feasible realizations and blockers, but it cannot select a production owner or required realization unless an exact current marked technical Source Item already makes that choice. Role labels, same-file prose and path-only claims are not authority.
-- Before commissioning a page, flow or complex control, consume controlling Product/Surface/Screen Source for target user/context, client/host, page duty, primary task outcome, primary work object/task loop, operation-object-feedback and applicable state/recovery/accessibility meaning. Separately consume `DESIGN.md` and selected exact-target/constraint Source for visual-system and selected-design conditions. If the requested direction requires durable Product/Surface/Screen/Design meaning to change, route to and update the actual owner before resuming generation; do not design against stale Source.
-- Non-authoritative task-level UI/UX analysis may inform candidate comparison but cannot supply missing product or surface meaning. A Provider must not infer that meaning from a feature list, screenshot, route tree, component inventory or analysis output.
-- Do not install/configure MCP, plugins, authentication or disclosure paths without separate authorization. Create no provider registry, global workflow state, authority lifecycle, scheduler or acceptance record.
-
-## Progressive references
-
-1. Always read [resource-selection.md](references/resource-selection.md) to fix the scope ceiling, authoritative product/surface inputs, intent, input roles, style dependency and minimum commission.
-2. Read [open-design-provider.md](references/open-design-provider.md) only before live capability discovery, provider execution, Design Authority binding, source acquisition or recovery.
-3. Read [downstream-handoff.md](references/downstream-handoff.md) only when selection, proposal reconciliation or downstream handoff is material. A simple unselected preview may stop without it.
-4. Read [authority-delta-assessment.md](references/authority-delta-assessment.md) after task-direction selection whenever a downstream handoff is being prepared. It owns the lightweight post-DRA system-delta judgment and explicit DSA stop.
-5. Read [implementation-feasibility.md](references/implementation-feasibility.md) before commissioning or publishing a Web/App implementation handoff against a real repository substrate. Reference-only and non-implementation resources never load it.
-6. Read [formal-selected-web-app-handoff.md](references/formal-selected-web-app-handoff.md) completely only for an explicitly final selected Web/App implementation handoff. Exploration, unselected previews, reference-only resources and non-Web/App commissions never load this reference.
-
-For simple-preview overhead accounting, the requested preview is neither additional Provider generation nor an added tool action.
-
-## Workflow
-
-1. Name in-scope surfaces/flows/regions/component families/unique controls, conditions, necessary context, exclusions and intent: `exploration`, `handoff` or `selected-source-preparation`. For a page, flow or complex control, first resolve controlling Product/Surface/Screen user/context, client/host, page-duty, primary-task, primary-work-object/task-loop, operation-object-feedback and applicable state/recovery/accessibility meaning; separately resolve `DESIGN.md` and selected-target visual conditions. Keep missing meaning unresolved, route a durable owner change before generation and keep outside-ceiling impact `decision-required` rather than filling it from task analysis or expanding scope.
-2. Inventory every input as `exact-target`, `constraint`, `inspiration`, current-implementation evidence or background. Report unreadable/unused material.
-3. Classify the commission `style-bearing` or `non-fidelity`. Style-bearing means high fidelity/brand/visual direction/typography/color/density/component treatment/production-style prototype. IA/flow topology, low-fidelity structure and semantics-only state studies are non-fidelity.
-4. For style-bearing work, read configured Design Authority and its exact-value token source. If unconfigured, stop before provider project/run creation and route the user to explicit `$design-system-authoring`; never invoke it automatically. Non-fidelity work remains allowed.
-   A combined explicit request authorizes running `$design-system-authoring` first and then resuming this Skill.
-   Before every style-bearing generation or material revision, use the always-read resource-selection reference to close every applicable current-slice style-application dimension as `existing-covered`, `projected`, `not-applicable` or the existing `decision-required`. No applicable dimension may be silently omitted; `decision-required`, an undispositioned dimension or Source conflict blocks the Provider run. Complete current input-bound coverage permits omitting `style_application`, while the actual envelope contains only `projected` fields; generic design-system identity or Tokens alone are not current-slice coverage. Repeat the judgment for each material revision. A simple preview performs it through the current Source/envelope action without another tool action, persistent state or fixed extra user turn.
-5. For a Web/App implementation handoff, inspect current technical Source for platform, framework/runtime, UI system, token/theming adapter, component-owner roots and route-owner roots. Owner roots are current no-follow repository directories, not arbitrary identifiers. Treat every unavailable or decision-required observation as target-wide: an exact Source-backed blocker naming that observation must reach every material component-family × condition cell, and a target with no family carrier cannot hide the unresolved observation. Cover every material component-family × target × condition profile, including the complete transitive family subject closure, with at least one Source-backed feasible realization or an explicit blocker. A candidate-bearing cell requires observed non-empty component-owner roots; unresolved roots force blocker-only coverage. Exact planned-owner authorization, required realization and blocker authority use the marked-Source decision projection defined by the feasibility reference. Keep canonical design values in design resources; never put them into any feasibility prose field, while explicit technical build/test/runtime costs may retain their time units.
-6. Discover only the live provider capabilities needed by the bounded commission. For a formal generation, major revision or critical regeneration, apply the provider reference's `highest_available_capability + highest_supported_reasoning_effort` policy and fail closed when eligible candidates cannot be authoritatively ranked; never infer rank from price, name, release date or list order, and never claim an effective model/effort the run cannot confirm. Give every considered resource one disposition—`selected`, `optional`, `not-needed`, `unavailable` or `decision-required`—with a reason. Ask only when a missing preference materially changes the result.
-7. Bind style-bearing provider work to the adopted design-system identity, send only the scoped product/resource commission and keep provider execution, model-selection verification, Artifact readiness, Design suitability, human selection and authority adoption distinct.
-8. Iterate within scope. Re-review applicable suitability checks after every material revision. A first render with no material Source, feasibility or suitability defect may be selected directly; never require a revision merely to satisfy process. Exploration returns a visible candidate after minimal sanity review. When direction review or selection is material, use the downstream owner's `Design Resource Review & Selection Stop`; it is not approval, acceptance, formal completeness or persistent state. Do not burden exploration with handoff schema, hashes, complete Fact closure or downstream validation.
-9. After direction selection, preserve canonical immutable identity and editable-upstream provenance. For a selected formal Web/App handoff, complete the formal reference's closure first and return to the review stop if it exposes a new visible decision. Reconcile accepted proposal effects once only after stable formal closure; non-formal small requests retain their one-turn option.
-10. Before downstream handoff, perform the reference-owned Authority Delta Assessment against the complete current Design Authority closure. `consistent_with_current_authority` continues without DSA; a task-only variance declares forbidden precedent; a reusable local variance requires its durable owner decision; an `authority_delta_candidate` returns a non-authoritative packet and stops for a separate explicit `$design-system-authoring` invocation. After adoption, rebind the handoff to the new closure identity and rerun affected validation.
-
-## Conditional Design Authority stop
-
-Unconfigured includes a missing `DESIGN.md`, the starter/status `unconfigured`, style-only prose/inspiration or no authored exact-value token source/generation direction. Say:
-
-```text
-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.
-```
-
-## Routing and output
-
-Route durable system adoption/repair to `context_uiux_design`, surface responsibility to `context_surface_contract`, ordinary implementation to the default Workflow Contract/current Goal, and machine-assurance delivery to an explicitly selected/resumed `long-task-workflow`.
-
-Report intent-sized results: scope/context/exclusions, style gate, input roles, resource dispositions, provider/binding status, visible artifacts/locators, selection basis, immutable/editable provenance, limitations/decision gaps, proposal-reconciliation status and exactly one Authority Delta Assessment when a handoff is prepared. A formal handoff additionally reports exactly what its dedicated reference requires. Never call a failing, unresolved, incomplete or unselected result ready.

package/assets/skills/design-resource-authoring/references/authority-delta-assessment.md

@@ -1,52 +0,0 @@
-# Authority Delta Assessment
-
-Run this lightweight assessment only after the task resource direction is selected and, for a formal Web/App handoff, its selected-source closure is stable. It asks whether the selected task design changes durable Design Authority. It is neither Proposal–Resource reconciliation nor an acceptance/adoption Gate.
-
-## Bind the current Authority
-
-Read the complete current project Design Authority closure. A new style-bearing or mixed handoff binds the exact `repository-closure` identity: `format_version`, root `DESIGN.md`, optional `design_system/authority.manifest.json`, closure digest and human revision diagnostic. Bundle format additionally requires the exact body-leading `<!-- ty-context-design-authority-format: bundle-v1 -->` declaration; marker/manifest mismatch is invalid rather than legacy. Legacy omission is only backward compatibility for a true unmarked one-file project. Never compare revision alone.
-
-If the closure changed after resource selection, re-read it and reassess the selected task design. Do not reuse a stale assessment.
-
-## Exactly three assessments
-
-### `consistent_with_current_authority`
-
-Use only when concrete current tokens/components/rules cover the selected task design and `observed_variances` is empty. Cite exact token keys, component keys and local Authority rule anchors. This is evidence-backed Agent judgment, not machine acceptance, and it does not invoke Design System Authoring.
-
-### `task_local_variance`
-
-Use for a deliberate deviation that must not silently become a system rule.
-
-- A one-task deviation declares `durability: task_only` and `precedent: forbidden`. It may remain in the task handoff, creates no cross-task memory and is never reused as precedent.
-- A reusable local rule declares `durability: cross_task_candidate` and one required Screen Contract owner. Before handoff, the user must explicitly update that owner, explicitly start Design System Authoring for a system-level rule, or abandon the durable claim. DRA changes neither owner automatically.
-
-State scope, reason and affected current rule anchors. Do not accumulate ownerless exceptions.
-
-### `authority_delta_candidate`
-
-Use only when the selected task design proposes a reusable long-lived Token, component, pattern, motion or platform change. Produce a non-authoritative packet based on the exact current closure identity, with keyed proposed changes/rationales, supporting resource anchors and representative scenarios. At least one proposal and one representative scenario are required.
-
-DRA stops after producing the packet. Tell the user to explicitly invoke `$design-system-authoring` in `reconcile` mode. DRA never invokes it, selects a system candidate or adopts Authority.
-
-## Strict data boundary
-
-When a replayable assessment file is warranted, use the package `design-authority-delta-assessment-v1` JSON shape and validate it read-only:
-
-```text
-ty-context design-resource authority-delta validate <assessment.json> --json
-```
-
-The codec accepts only:
-
-- `consistent_with_current_authority` with concrete evidence and no variance;
-- `task_local_variance` with exactly one durability branch;
-- `authority_delta_candidate` with the complete proposed-change categories.
-
-It rejects `status`, `passed`, `selected`, `adopted`, `authority_updated` and unknown fields. Validation proves structural integrity and current base identity only. It performs no write, selection, DSA invocation, adoption or production conformance.
-
-## Handoff consequence
-
-For `consistent_with_current_authority` and a valid task-only variance, return the assessment with the normal DRA handoff. A cross-task candidate blocks an unqualified durable-memory claim until its owner decision closes. An Authority delta candidate blocks system-adoption claims and waits for explicit DSA; the selected task resource may continue only as a user-approved task-only variance or after adoption/rebinding.
-
-After a DSA adoption, bind the DRA handoff to the new complete closure identity and rerun affected preflight/resource verification before downstream handoff. Page/resource selection never implies system adoption.

package/assets/skills/design-resource-authoring/references/downstream-handoff.md

@@ -1,67 +0,0 @@
-# Selection, Proposal Reconciliation And Downstream Handoff
-
-Generated resources remain ordinary external Source. Preserve enough identity and meaning for downstream work without creating a Tiny Context pack, registry, authority lifecycle or acceptance result.
-
-## Candidate, selection and adoption
-
-- **Candidate:** provider output proposed for review; it authorizes no fidelity.
-- **Selection:** explicit user/team choice, or explicit delegation with known criteria; it permits proposal reconciliation and selected-source preparation.
-- **Authority adoption:** later UI Authority Closure reconciles selected Source with surface/interaction Context and `DESIGN.md` and binds implementation/verification to declared conditions.
-
-Task-resource selection is not design-system adoption. Before downstream handoff, load the dedicated Authority Delta Assessment reference. DRA can classify the selected task design as current-system-consistent, a bounded local variance or a system-delta candidate; none of those classifications adopts Authority.
-
-This Skill may preserve an input already classified `exact-target`; it cannot promote its own candidate. Unknown coverage remains unknown. Resource hashes, provider success and previews establish neither selection nor production conformance.
-
-A selection binds the canonical selected-source digest, target identity, declared conditions and controlling Source/Design-Authority identity. Preview URLs, names, PNGs, export archives and wrappers are derived artifacts, not the selection identity. A derived artifact proved equivalent to that canonical source under the bound target/conditions preserves selection; a visible or semantic difference requires fresh Design suitability review and another user choice.
-
-## Development-scope coverage
-
-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 context and explicit exclusions. One addressable artifact may cover several items; a static/default frame covers only what it actually shows.
-
-Design resources may show user-visible triggers, transitions, states, feedback and rule presentation. Product/technical Source still owns business, data, permission and algorithmic rules.
-
-For a Web/App implementation handoff, also return the separate implementation-feasibility Source described in [implementation-feasibility.md](implementation-feasibility.md): real substrate observations plus complete transitive component-family × target × condition candidates/blockers. Owner roots are current repository directories. Planned-owner authorization, required realization and blocker authority bind exact marked technical Source Items and strict decision projections. Exact selected design values remain canonical-resource owned and cannot appear in feasibility prose. Multiple feasible candidates remain allowed; DRA selects none unless current technical authority already requires one.
-
-## Design Resource Review & Selection Stop
-
-Use this explicit interaction point when direction review, correction or candidate selection is material. Show the addressable candidate plus the scope ceiling/necessary context/exclusions, selected existing and generated coverage, preservation obligations, Provider/Artifact qualifiers, Design suitability findings, unchecked conditions, outside-ceiling effects and unresolved choices.
-
-The user may correct design execution, change a requirement, select/reject a candidate, leave a choice unresolved, explicitly expand scope or request a durable Product/Surface/Screen/Design owner change. Route durable meaning to its actual owner and reread it before DRA resumes. Design suitability never performs selection.
-
-This stop is not an approval record, `review_set_id`, registry, persisted status, Gate, acceptance, readiness or formal-completeness claim. It is not a required extra turn when a small request can generate, review and select in one turn. Ordinary conversational selection creates no persistent state or deterministic cross-session promise and must be reconfirmed if lost. When deterministic cross-interruption recovery is required, load [recovery-and-writeback.md](recovery-and-writeback.md) and use only its existing marked-Source, authority, selected-source and conditional-checkpoint route.
-
-## Reconcile the initial proposal once
-
-During a simple iteration, keep a task-local buffer of selection basis, selected immutable/editable identities, accepted decisions, rejected alternatives, unresolved choices and affected product/surface/control/state/interaction/visual keys. This is reasoning, not a schema or required file. If the loop is material enough to require replayable Delta, a file writeback or interruption recovery, stop and read [recovery-and-writeback.md](recovery-and-writeback.md); do not approximate safe recovery/CAS from this lightweight reference.
-
-After selection—and, for a formal Web/App handoff, only after its complete closure produces no new visible decision:
-
-1. confirm the selection basis and immutable identity;
-2. consolidate duplicate/intermediate notes;
-3. apply accepted decisions once while preserving unaffected requirements and provenance;
-4. keep rejected choices out of requirements and unresolved choices visibly unresolved;
-5. record stable resource keys and conditions, the immutable provider/project/run/entry locator plus digest/snapshot, and the editable upstream owner, locator and update/export method;
-6. make reruns idempotent by updating the existing decision/reference;
-7. edit the authorized writable initial-proposal file, or return one complete revised proposal when it exists only in conversation.
-
-Never mutate other caller-owned Source, Context, `DESIGN.md`, Contract, production code or tests. If no selection occurs, return candidates and the pending delta without changing the proposal. If formal closure exposes a new state, resource, condition, visible/semantic change or `decision-required` choice, return to the Review & Selection Stop before reconciliation.
-
-Non-formal small requests may complete generation, selection and reconciliation in one turn; “once” describes the semantic writeback, not a required pause. Formal Web/App work defers its one reconciliation until direction selection plus stable formal closure.
-
-## Intent-sized handoff
-
-Exploration returns the visible candidate, scope, dispositions, obvious limitations and sanity review. It requires no schema, pack, hash or validator unless retrieval itself needs one.
-
-A non-formal selected-source handoff preserves target/resource classification, conditions, immutable identity, editable-upstream route, coverage/limitations and proposal identity in a project-native location authorized by the user. It remains ordinary Source.
-
-Every prepared style-bearing or mixed handoff also binds the complete current project Design Authority closure, not only a human revision label or raw `DESIGN.md` digest. If a subordinate owner changes, the old handoff is stale even when revision text is unchanged. Legacy omission is backward compatibility only for a true one-file Authority.
-
-For an explicitly selected Web/App implementation handoff, stop here and read [implementation-feasibility.md](implementation-feasibility.md) followed by [formal-selected-web-app-handoff.md](formal-selected-web-app-handoff.md). UI symbolic V2 is explicit opt-in; V1 remains the default. Those references own the real-substrate feasibility Source, strict manifest-backed V1/symbolic V2, Census/Fact/method and bundle/preflight rules. If closure exposes a new visible decision, return here for suitability review and the Review & Selection Stop; only stable closure returns for the one Proposal reconciliation. Do not approximate formal rules from this lightweight reference.
-
-## Downstream routing
-
-The default Workflow opens every affected selected `exact-target` or `constraint` plus current feasibility Source, routes design meaning through owning surface/Design Authority, selects an allowed implementation strategy during Architecture Deliberation, implements through the real production entry, runs applicable current-candidate checks, and reports blockers or unestablished conditions. It does not infer system adoption from a selected task resource or require machine-unique binding selection. When no reliable project-native check observes a production claim, report it as `Unverified`; preflight or model judgment cannot promote it. It does not rebuild a per-Fact proof ledger.
-
-An active Long-Task uses its one Source/Contract/Authority/Final Gate lifecycle. Existing component bindings must uniquely derive an allowed realization for every candidate-bearing cell and must all be attributed back to an allowing candidate-bearing cell; shared bindings are attributed across the complete surface, not forced onto each target. A surface with empty component refs is admitted only by complete Source-aware activation when every target is all-blocker-only; standalone structure validation, candidate/mixed/legacy targets and fake component bindings remain strict failures. Every `file`/`path_glob` target and carrier, every `verified` carrier and every non-empty planned carrier must be a proven subset of an observed component or route root; partial or unknown containment fails. Exact `path#source-item-key` Claims carry selected planned-owner/required-realization decisions, while every blocker is either `decision_required` or an open/closed target-blocking External Confirmation over affected current-target Claims. An open confirmation may project only its externally blocked design Assertions from machine execution and reaches `blocked_external`, never `machine_accepted`; it does not mutate the Contract or create a second Gate. The resource handoff, feasibility document and controlling technical authority are Source and bind only through existing Contract surfaces; this Skill creates no Contract Draft, Outcome, Progress, Evidence, Receipt, Check result or Gate. Historical Provider, preflight, DRA-audit or project-check results never replace current-candidate evidence in the existing Final Gate.
-
-Never infer that a generated resource is selected/authoritative/accepted, covers undeclared states or targets, is native implementation because a preview renders, changed durable authority, or proves production fidelity, tests or release readiness.