project-tiny-context-harness 0.12.0 → 0.12.1

package/README.md

@@ -2,7 +2,7 @@
 
 Tiny Context preserves durable project facts and installs a short development contract in `AGENTS.md`. It helps a coding agent find project-specific requirements and maintain them without prescribing an engineering workflow.
 
-This source version is **0.12.0**, configuration schema **5**, update mode **upgrade-required** for schema-4 installations. See the [migration notes](https://github.com/Seven128/project-tiny-context-harness/blob/main/packages/ty-context/migrations/README.md).
+This source version is **0.12.1**, configuration schema **5**, update mode **upgrade-required** for schema-4 installations. See the [migration notes](https://github.com/Seven128/project-tiny-context-harness/blob/main/packages/ty-context/migrations/README.md).
 
 ## Start with little
 
@@ -61,6 +61,61 @@ triggers = ["payment recovery"]
 
 `default_files` selects literal body files without activating their children. Areas and workspace folders can be sparse. Ordinary search and inspection discover additional owners; reading them does not authorize changing unrelated projects.
 
+Locate owners from the affected implementation, not only manifest trigger words. Before a substantial capability change, the development contract asks agents to inspect consumers, state/data ownership and dependency direction, and to reuse suitable project and target-platform capabilities. Shared responsibilities that need to evolve together merit a shared owner and migration of affected consumers; visual similarity or a repetition count alone does not. New dependencies or substantial custom machinery merit bounded investigation of material gaps in mature alternatives, reusing decisions whose conditions still hold. A local style or condition fix does not require a fresh architecture or library survey.
+
+## Use design resources as scoped inputs
+
+Keep sources, visuals, prototypes, assets and exploration records outside Context, in an existing resource location or optionally `docs/design-resources/`. The existing page, component or feature owner keeps the current adopted entry, applicable scope and confirmed decisions with reasons. Shared resources belong to a shared owner; other owners link there. Global Context needs only useful brief navigation, not resource inventories or generation history.
+
+For example, an existing owner can declare a local entry:
+
+```markdown
+<!-- ty-context-controlling-source domain="design" path="docs/design-resources/web/results/ADOPTED.md" -->
+
+This entry controls result-list composition and assets for desktop, light theme
+and populated results. Business and state meaning remain with this owner;
+shared visual rules remain with the existing shared design owner. Other regions,
+themes and states retain their current requirements.
+```
+
+The entry can map several nonconflicting scopes to different resources; one applicable scope has one current basis. A newer candidate or a preference during exploration does not supersede an adopted resource. Authorized partial adoption replaces only its scope, reconciles affected rules and preserves the remaining valid references. Images do not silently override business, accessibility or platform constraints, and stale rules must not silently negate an authorized design change. Keep indices as navigation to the decision owner, repairing relevant stale references without concealing unfinished implementation.
+
+Development follows defaults and affected owners to their current entry, then opens the relevant sources, actually views current visuals and inspects necessary prototypes or behavior descriptions. Adopted resources are implementation requirements within their declared scope. Compare the real target runtime under meaningful conditions such as viewport, fonts, theme, data and dynamic state, and repair deviations. The entry identifies illustrative content outside production scope and project adaptation rules; different screen sizes need not be scaled into one image. Report missing inputs, conflicts, platform limits and unverified scope. Ordinary repairs reuse existing resources; they do not require regeneration, another adoption decision or invocation of a resource Skill.
+
+The existing declaration checks a repository-relative local UTF-8 entry. It does not recursively check linked assets or declarations inside that entry, load images, visit external links or add resources to default Context. Declare a shared entry once in its owning Context: duplicate declarations of the same target are diagnosed, even in the same domain. Different targets with overlapping prose scopes require review; the validator cannot infer those collisions. Resource usability and runtime checks are explicit task work. Structural success proves neither adoption, agent viewing, aesthetics nor production correctness.
+
+### Optional resource creation and adoption Skill
+
+The package includes `assets/skills/design-resource/`, containing `SKILL.md`, `references/stitch.md`, `references/adoption.md` and `agents/openai.yaml`. The capability uses **Stitch for visual generation and design revisions**, with official MCP first and the authenticated official Stitch website when a needed operation is unavailable through MCP. It preserves actual editable sources and exports, records reference purpose and necessary versions, distinguishes original outputs from revisions, and reports screenshot-only or missing-input limits honestly. Scope and iterations follow the task; project Context supplies style and design rules. Read the [resource capability](https://github.com/Seven128/project-tiny-context-harness/blob/main/.codex/ty-context-managed/skills/design-resource/SKILL.md), [Stitch operation reference](https://github.com/Seven128/project-tiny-context-harness/blob/main/.codex/ty-context-managed/skills/design-resource/references/stitch.md) and [adoption guidance](https://github.com/Seven128/project-tiny-context-harness/blob/main/.codex/ty-context-managed/skills/design-resource/references/adoption.md), or the corresponding installed files.
+
+The Stitch reference covers live tool/schema discovery, project and screen identity, initial generation, selected-screen edits, requested variants, uncertain-write recovery and retrieval of original HTML/images. It requires actual refreshed output inspection and avoids duplicate generation after an uncertain timeout. Tool signatures are checked against the connected service; a listed tool or successful transport is not proof of a usable design. A local image path in a prompt is not an upload: use an available Stitch attachment/upload operation or the official web flow. If neither Stitch route works, report the missing capability and retain the input bundle; do not silently switch providers. Existing-resource reading and adoption can continue independently.
+
+`agents/openai.yaml` declares the Stitch MCP dependency for hosts that support this metadata. The connection uses `https://stitch.googleapis.com/mcp`; configure authentication through the host's supported mechanism using existing authorized credentials. The Skill does not install a server, obtain credentials or edit global settings. Copying or reading a Skill alone does not make its MCP available, and reading the base from a project wrapper does not automatically load the base's metadata. Supporting hosts can use the dependency hint; other hosts need the connection configured separately. Keep authentication values out of project files and logs. See the [official connection configuration](https://github.com/gemini-cli-extensions/stitch/blob/e22b3aac9a43bce2d740c5172844e9a2eebba37f/gemini-extension-apikey.json) and [Stitch setup](https://stitch.withgoogle.com/docs/mcp/setup).
+
+To opt in, use a project Skill that reads the packaged capability as described below, or copy the **entire** `node_modules/project-tiny-context-harness/assets/skills/design-resource/` directory into your host's supported project Skill location, preserving `references/` and `agents/`. Choose an unused destination; if a local copy exists, review and merge it instead of overwriting project changes. Consult your host's discovery rules and reload as needed. Project Skills and copied Skills are project-owned: `init`, `sync` and `upgrade` do not install or update them. No design directory or resource template is created automatically.
+
+The managed `AGENTS.md` block remains the generic development entry; this optional Skill is for resource work and does not restore retired design commands or replace the startup contract. An old development Skill does not need to remain enabled alongside it. Explicit upgrade handles supported historical managed assets; project-authored Skills and instructions still need their own review. Already loaded instructions do not change when a file is synced, and host loading is distinct from file installation.
+
+### Extend it in a project
+
+For projects with their own resource Skill, keep that entry and compose the packaged capability into it. The project entry can add target-platform handling, reference conventions, export/integration procedures and project-specific checks while reading design requirements from their existing Context owners. Stitch remains the generator and visual editor; a wrapper must not silently substitute another provider. Other tools may inspect or package results and perform an explicitly needed downstream conversion. Route resource tasks to the project entry through the host's Skill discovery or the project's own AGENTS prose. There is no automatic `extends` field or extension-directory scan.
+
+An illustrative project Skill can contain:
+
+```markdown
+Read the project's default Context and affected owners.
+Read node_modules/project-tiny-context-harness/assets/skills/design-resource/SKILL.md
+from the repository root; resolve its relative references from that file's directory.
+Use its Stitch route for generation and visual revision, together with this Skill's
+target-platform and integration methods. Keep durable design rules in their owning Context.
+```
+
+Use the actual installed package location if the project has a different dependency layout. Keep the project Skill outside `node_modules` and the managed AGENTS block. Referencing the packaged base avoids maintaining another copy of its generic instructions: an intentional dependency update updates the base, while local extension methods remain project-owned. Review upstream changes for conflicts with those methods. If a frozen local copy is preferred, update it by deliberate comparison and merge; `sync` does not refresh it. If the referenced package is unavailable, report the missing base instead of pretending it was read.
+
+Confirmed style, visual principles, business meaning and interaction rules belong in Context, with their scope and rationale. Design techniques and tool procedures belong in the project Skill. Exact token values, component implementations and design-source entities remain in their actual code or design files; Context links to them instead of duplicating a second inventory. A project does not need to rename or consolidate its existing Context files to use this capability.
+
+For an existing schema-5 installation, install a package version containing this capability and run its local `ty-context sync` to refresh the managed startup block. This addition does not require a schema migration: project Context, resources, local Skills and prose outside that block remain project-owned. Retain existing adopted entries and resource scopes; moving methods into a wrapper does not require regenerating or re-adopting designs. Review overlapping generic instructions in the local Skill when choosing to reuse the base. Schema-4 installations still follow the explicit upgrade procedure below. These are the package's supported boundaries, not a claim that any particular project's current installation has already been inspected or migrated.
+
 ## Maintain files safely
 
 ```sh

package/assets/agents/AGENTS_CORE.md

@@ -4,11 +4,12 @@ Tiny Context preserves durable project facts and this short development contract
 
 - Understand the user's requirements, default Context and relevant owners. Use clear source material directly; clarify real gaps without manufacturing plans, design documents or handoffs.
 - Start with `project_context/global.md` and project-declared defaults. `ty-context context list --default` is optional. Without the CLI, read the manifest directly: default Areas, `read_policy = "default"` nodes and their transitive `default_children`; `default_files` selects files without traversing their children. Pre-schema-5 projects also default to architecture.md. Do not install a CLI over the network merely to read files, or repeat unchanged reads. A failed query is not an empty set: resolve uncertainties material to the current change and report the remainder.
-- Follow relevant dependencies to additional Context. Reading other workspaces does not authorize editing them. Stay within the user's scope, preserve unrelated changes and respect project business, technical and safety constraints. Distinguish requirements from current implementation; do not rewrite requirements to conceal conflicts.
-- Choose implementation order, tools, decomposition and parallelism as appropriate. Reuse suitable existing owners, components and mature capabilities. Avoid unnecessary abstraction and complete the required change.
-- UI may be implemented and iterated directly from conversation, references and code. Reuse confirmed direction and shared components, inspect real results and fix concrete problems. An independent design system or formal handoff is not a prerequisite; existing user design decisions still apply.
-- Choose checks based on requirements, risk and project rules. Reuse existing tests, add meaningful regressions when needed and observe actual outputs. Derive expectations from requirements rather than copying implementation. Repair failures and rerun affected checks after relevant input changes; do not repeatedly broaden checks without a new change, failure or specific concern.
-- Update the owning Context only when durable project facts change. Keep project-specific goals, boundaries, confirmed decisions, reasons and useful entrypoints; reference exact values rather than duplicating code. Optional cross-session handoff information stays task-local, outside durable Context.
-- Report implementation, actual checks and material unresolved items honestly. Explain unverified scope and necessary human action. Historical results, tool success and subagent summaries do not establish current product correctness.
+- Identify relevant owners from the affected implementation and follow their dependencies and current controlling sources, without waiting for a trigger keyword. Reading other workspaces does not authorize editing them. Stay within the user's scope, preserve unrelated changes and respect project business, technical and safety constraints. Distinguish requirements from current implementation; do not rewrite requirements to conceal conflicts.
+- Choose implementation order, tools, decomposition and parallelism as appropriate. Before adding or materially extending a capability, inspect its owners, consumers, state/data responsibility and dependency direction. Reuse suitable capabilities from the project and target platform. Extract a shared unit when consumers must evolve together in the same responsibility, including a shared role already required on first implementation; migrate affected consumers within scope. Avoid speculative abstraction and unification based only on appearance, size or repetition. Complete the required change.
+- Before adopting a new dependency or building substantial custom machinery, consider suitable mature alternatives. Reuse decisions whose conditions still hold; bound investigation to material gaps in target support, behavior, customization, maintenance, license and integration cost. Use a small runtime trial when needed to resolve uncertainty. Suitability, not popularity, decides; justified custom implementation remains valid. Local fixes do not trigger a new selection exercise.
+- UI may be implemented and iterated directly from conversation, references and code; an independent design system or formal handoff is not a prerequisite. Reuse confirmed direction and shared components. For affected UI with adopted resources, follow the owner's current reference and scope, actually view current visual references and inspect relevant prototypes or source and behavior descriptions. Adopted resources are requirements within their declared scope. Implement faithfully in the target runtime, compare actual results under relevant comparable conditions and repair deviations. Resolve and report inaccessible inputs, conflicts or platform limits; continue independent work. Do not silently replace confirmed designs. Ordinary repairs reuse current resources without regeneration or renewed adoption; authorized design changes update affected resources and owners.
+- Choose checks based on requirements, risk and project rules, including changed boundaries, affected consumers and relevant lifecycle/failure behavior. Reuse existing tests, add meaningful regressions when needed and observe actual outputs. Derive expectations from requirements rather than copying implementation. Repair failures and rerun affected checks after relevant input changes; do not repeatedly broaden checks without a new change, failure or specific concern.
+- Update the owning Context only when durable project facts change. Keep project-specific goals, boundaries, confirmed decisions (including adopted/rejected choices), reasons, material reassessment conditions and useful entrypoints; reference exact values rather than duplicating code. Keep current resource references and scope with their owner, resources outside Context, and indices as navigation; repair relevant stale references. Optional cross-session handoff information and temporary investigation records stay task-local, outside durable Context.
+- Report implementation, decisive tradeoffs, actual checks and material unresolved items honestly. Explain unverified scope and necessary human action. Installed instructions, structural validation, design adoption, static previews, historical results, tool success and subagent summaries do not establish current product correctness or agent compliance.
 
 This contract applies to authorized implementation, including code, configuration, tests, documents and resources. Reading, discussion and audit do not themselves authorize edits. User scope, host safety requirements and more specific valid project constraints take precedence. No role workflow, mandatory intermediate artifact, model checkpoint or machine acceptance Gate is required.

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

@@ -0,0 +1,40 @@
+---
+name: design-resource
+description: Create and revise design resources with Stitch, preserve editable sources, and package or adopt scoped project references. Use for resource work; implementing or repairing an already adopted design does not require invoking this skill.
+---
+
+# Design resources
+
+Deliver resources that people and agents can inspect and continue editing. Use Stitch for visual generation and design revisions, following the user's design direction and project constraints. This capability selects the tool; project Context supplies design rules, style and business meaning. It adds no fixed target platform or task workflow.
+
+## Project extensions
+
+This capability can be used directly or composed into an existing project resource Skill. Apply relevant project-declared target-platform, reference, export and integration methods alongside it; reuse an already loaded extension without creating a circular read. Keep Stitch as the generator and visual editor; a wrapper must not silently substitute another provider. A project Skill may reference this installed entry and then supply its own methods instead of copying the generic instructions. Resolve this entry's relative references from its own directory. This is instruction composition, not an automatic extension loader.
+
+Project Context owns confirmed style, design principles, business and interaction rules, scope and decisions with reasons. Tool operations, design methods and repeatable procedures belong in the project's Skill. Keep exact tokens, component definitions and resource entities in their actual source files or design tools, with Context pointing to those owners. Project-specific constraints refine this general capability; handle a material conflict explicitly under the user's requirements rather than silently replacing either source.
+
+## Create or revise resources
+
+Read the user input, default Context, affected owners, existing design rules and necessary implementation. Separate constraints to preserve, confirmed choices, requested changes and open exploration. Follow owners from the affected page, component or capability even when the request does not mention design resources. Existing project organization is sufficient; no new design document is a prerequisite.
+
+Continue a selected direction. Choose the number of alternatives, iterations and covered pages or states from the task; a selection is not necessarily formal adoption. Do not manufacture another revision when none is requested.
+
+For generation or visual revision, read [Stitch MCP operations](references/stitch.md). Discover and use the official Stitch MCP first, verifying current tool schemas and project/screen identifiers. When a required operation is unavailable there, use the authenticated official Stitch website if available. If neither route works, report the specific missing capability and preserve a usable input bundle; do not silently switch generators. Existing-resource inspection, packaging and adoption can continue without making a generation connection a prerequisite.
+
+Verify actual editing and export support. Preserve available editable sources, stable project links and supported exports. Other tools may inspect, package or perform a requested downstream conversion; they do not replace Stitch generation or disguise later repairs as Stitch originals. A screenshot, HTML prototype and native design nodes have different capabilities; label them accurately and verify any requested conversion by opening its result.
+
+Keep key inputs, reference origins and intended use, original outputs and necessary before/after versions with the resource or task material. Distinguish generated originals from later human or agent revisions. Inspect the current rendered result; an older preview does not represent a changed source. Keep prompts and detailed run records outside durable Context, with model, usage or hashes only when the task needs them.
+
+## Make the result usable
+
+Check what the task requires: files and links open, available sources can be edited, exports render, and the delivered content covers the stated scope. Actually view relevant visual outputs; inspect adopted motion or interaction through an available prototype, or its source and behavior notes as appropriate. Report inaccessible inputs and missing assets, fonts, permissions, states or runnable prototypes with their affected scope. Continue independent work when possible. Do not invent an editable source for a screenshot-only result or claim an unperformed check.
+
+Use the project's existing resource location; `docs/design-resources/` is an optional default. Keep resource entities outside Context. A useful entry links the available source, current visual references, assets and their origins, necessary behavior notes, coverage, limitations and comparison conditions. Create only the directories and records needed for that handover; an external design file can remain a stable link, with obtainable local exports when useful for continued access.
+
+Record comparison conditions that materially affect the result, such as viewport, fonts, data state, theme, safe areas and dynamic state. Identify which illustrative data, backgrounds, system chrome or decorative simulations are outside the implementation scope. Project adaptation rules determine responsive behavior; do not assume that different screens should be scaled into one reference image.
+
+## Adopt within the authorized scope
+
+For adoption or changes to current resource references, read [adoption and Context ownership](references/adoption.md). Preserve the distinction between a candidate, a preferred direction and an adopted requirement. Existing explicit authorization is sufficient to apply adoption; clarify only unresolved decisions or scope that matter to the change.
+
+Hand over a current entry that lets development find the relevant materials without replaying exploration history. Implementers follow the project's startup contract and affected owners; they do not need to run this generation skill again for ordinary repairs. Resource adoption and structural checks establish neither aesthetic approval nor verified production implementation.

package/assets/skills/design-resource/agents/openai.yaml

@@ -0,0 +1,7 @@
+dependencies:
+  tools:
+    - type: "mcp"
+      value: "stitch"
+      description: "Google Stitch for design generation and visual revision"
+      transport: "streamable_http"
+      url: "https://stitch.googleapis.com/mcp"

package/assets/skills/design-resource/references/adoption.md

@@ -0,0 +1,56 @@
+# Adoption and Context ownership
+
+Use the existing owner and manifest mechanisms. Adoption changes the project's implementation requirements only within its confirmed scope; it is not a new registry, approval workflow or task state machine.
+
+## Current basis and scope
+
+A candidate is an exploration. A preferred direction guides further work. An adopted resource is a current requirement within its declared scope. A newer file, generation success or attractive preview cannot make that decision. Use the user's existing authorization; do not ask again for an already approved adoption. If adoption is undecided, retain the current basis and report the candidate without silently changing requirements.
+
+The affected Context owner keeps the current entry, object and applicable platform, component or region, state and theme, as needed to distinguish it from other requirements. One scope has one current basis; an entry may map several nonconflicting scopes to different resources. Partial adoption replaces only the affected scope and preserves the remaining valid references. Shared component resources belong to the shared owner; page owners link there instead of repeating its rules.
+
+Resolve affected authority conflicts as part of authorized adoption. Business meaning, shared design rules, accessibility and platform constraints retain their respective owners. Update superseded decisions and stale navigation within scope; neither an image nor an old rule silently overrides the others. Distinguish an approved requirement from an implementation that has not yet caught up. If the decision needed to resolve a conflict is not authorized or clear, explain that conflict and preserve the unresolved requirement rather than fabricating agreement.
+
+## Resource location and entry
+
+Use an existing equivalent layout when present. This is an example, not required scaffolding:
+
+```text
+project_context/areas/<area>/<owner>.md
+docs/design-resources/<surface>/<component>/
+  ADOPTED.md                  # Current entry mapping resources to scopes
+  adopted/<resource>/
+    README.md                 # Opening, coverage, behavior, comparison conditions
+    source/                   # Available editable sources or prototype
+    reference/                # Current visual or motion references
+    assets/                   # Necessary assets and origins
+  candidates/<run>/           # Exploration and revision material when needed
+```
+
+The names, folders and local-file layout are optional. Stable external project links are valid resources; preserve available exports when needed to reduce access or remote-change risk. Do not imply a local export is editable or that it matches the current remote version without checking.
+
+Context holds durable adoption references, scope, confirmed decisions, reasons and authority boundaries. Source files, images, videos, asset lists, prompts, generation history and comparison evidence stay with resources or task material. Task progress and implementation migration notes stay task-local. Global Context needs only useful brief navigation; resource directories do not become default Context because an owner links to them.
+
+## Reuse the existing source declaration
+
+An existing component or feature owner may include this declaration and prose, adapted to the project's actual scope:
+
+```markdown
+<!-- ty-context-controlling-source domain="design" path="docs/design-resources/web/results/ADOPTED.md" -->
+
+The current result-list composition and assets are requirements for desktop,
+light theme and populated results, through the entry above. This owner retains
+business and state meaning; shared visual rules belong to the existing shared
+design owner. Other regions, themes and states retain their current requirements.
+```
+
+The path is repository-relative and names a local UTF-8 entry, not an image or design binary. Register the owner only as needed using the existing manifest. Declare a shared entry once in its owning Context; other owners link that owner, since duplicate declarations of the same target are diagnosed even within the same domain. Ordinary historical or candidate links are not controlling declarations. A required local text dependency can be explicitly declared from Context; links or declarations inside a resource entry outside Context are not recursively validated. Media files and remote resources require the appropriate explicit checks when the task needs them.
+
+Development follows defaults and affected owners to the current entry, then reads relevant sources and behavior notes and actually views the current visuals. Scope does not depend on the user saying a trigger keyword. Missing current inputs are reported as specific missing constraints, never reinterpreted as an unconstrained design. Access limitations can leave a portion unverified while independent work continues.
+
+## Implementation and evidence boundary
+
+Within the adopted scope, implement faithfully in the target runtime and compare the actual UI and relevant behavior under the entry's material comparison conditions. Check owned layout, typography, colors, icons, assets and interaction as relevant. Report and resolve platform limitations and conflicts. Ordinary fixes follow existing adopted resources; authorized design changes update resources and their owners. Never revise design requirements just to make current code pass a comparison.
+
+`validate-context` checks declared local paths, canonical identities, safety, UTF-8 readability and supported ownership conflicts. It does not recursively load images or prototypes, check remote access, run design tools, infer natural-language scope collisions or establish resource-bundle completeness. Overlapping design scopes need review; existing duplicate/domain diagnostics concern declarations of the same target, not semantic design agreement.
+
+Neither these files nor a successful check prove user approval, agent viewing, a preview's correspondence to current code, aesthetic quality, working interaction or production completion. Report the actual resource and implementation checks separately. Do not add a design preflight, fixed handoff document, hash gate or completion certificate.

package/assets/skills/design-resource/references/stitch.md

@@ -0,0 +1,54 @@
+# Stitch MCP operations
+
+Use this reference when generating or visually revising design resources. Stitch is the selected provider: prefer its official MCP connection, with its authenticated official website as a fallback for a needed operation. Keep project style, business and interaction requirements in their existing Context owners. Reading or adopting existing resources does not require a new Stitch submission.
+
+## Connect and discover
+
+Discover the host's available Stitch tools and read their descriptions and input schemas before calling them. Tool prefixes vary by host; the operation names below are discovery targets, not a promise that a particular prefixed function exists. If the host offers deferred tool discovery, use it before concluding that the connection is absent. With an existing MCP client, use its normal initialization and `tools/list`; do not build a new adapter or install another agent CLI just for this capability.
+
+The endpoint is `https://stitch.googleapis.com/mcp` over Streamable HTTP. The official extension supports a Stitch API key through `X-Goog-Api-Key`, or Google credentials with a quota project. Reuse an authorized connection and the host's supported secret storage; do not copy keys, tokens or authentication headers into prompts, resource records, code or terminal output. `agents/openai.yaml` provides a dependency hint for supporting hosts; copying this Skill does not authenticate a connection or modify host configuration. See [API-key connection](https://github.com/gemini-cli-extensions/stitch/blob/e22b3aac9a43bce2d740c5172844e9a2eebba37f/gemini-extension-apikey.json), [Google-credentials connection](https://github.com/gemini-cli-extensions/stitch/blob/e22b3aac9a43bce2d740c5172844e9a2eebba37f/gemini-extension-adc.json) and [current setup](https://stitch.withgoogle.com/docs/mcp/setup).
+
+Verify the needed connection through a relevant read, such as the known project or its screens, before submitting generation. A listed tool is not evidence of account access. If connection setup is needed, follow the current official instructions and task authorization. If a missing login or permission cannot be resolved, explain the exact prerequisite and continue independent work. Do not silently use a different generator.
+
+## Choose the operation and target
+
+The Google Labs published SDK manifest provides the following call shapes. It is a reference snapshot, not a guaranteed live service schema; use the connected tool's current schema and supported values. Do not hardcode a model list or create a design system merely because an optional parameter exists. [Published tool manifest](https://github.com/google-labs-code/stitch-sdk/blob/575a9fb6319bd9d1ce8175e4a89e5958e024bbfd/packages/sdk/generated/tools-manifest.json)
+
+| Intent | Operation and arguments to verify |
+| --- | --- |
+| Find the intended existing project | `list_projects` with optional `filter`; `get_project` with `name: projects/{projectId}` |
+| Create a project when the task needs one | `create_project` with optional `title`; retain its returned identity |
+| Find and read selected screens | `list_screens` with `projectId`; `get_screen` with `name: projects/{projectId}/screens/{screenId}` |
+| Generate an initial screen | `generate_screen_from_text` with `projectId`, `prompt`; optional `deviceType`, `modelId`, `designSystem` only when appropriate and supported |
+| Revise the chosen screen | `edit_screens` with `projectId`, `selectedScreenIds`, `prompt`; optional supported device/model settings |
+| Explore requested alternatives of selected screens | `generate_variants` with `projectId`, `selectedScreenIds`, `prompt`, `variantOptions` |
+
+Use returned identities and the user's selected scope. Names are resource paths; project and selected-screen IDs are bare IDs where the live schema requests them. The published `get_screen` schema also requires deprecated `projectId` and `screenId` alongside `name`; if the live schema does too, supply consistent values for all three. Never guess an ID or use the most recent unrelated screen as the target. Inspect selected screens before editing and retain the before version.
+
+For a new design, reuse the intended project or create a task-appropriate one. For continuation, edit the selected screen instead of restarting generation. Variants are an explicit exploration choice: choose any `variantCount`, `creativeRange` and `aspects` from the user's requested scope and live schema, not a fixed comparison ritual. Preserve additional returned candidates without silently adopting or expanding work to them. [Stitch generation and revision examples](https://github.com/google-labs-code/stitch-skills/blob/0337446dadde6f8c94210444e2aa9d546126480f/plugins/stitch-design/skills/generate-design/SKILL.md)
+
+## Submit useful inputs
+
+Separate content/actions that must remain, confirmed visual direction, requested changes, disliked problems and still-open exploration. Identify a reference's relevant region and purpose; liking one region does not approve the whole candidate. Label agent inferences and technical findings separately from user preferences. Send these focused inputs to Stitch, preserving confirmed design values without inventing a full typography/spacing system as a prerequisite. Do not include unrelated task history or another tool's commands.
+
+A path written into a text prompt does not upload an image. When image input is required, inspect the actual upload or attachment capability. Use a supported Stitch upload and its returned asset/screen identity, or the official website's real upload/paste flow. Confirm the correct reference reached the target. Do not add invented local-file or image-data parameters to text-generation/edit tools. If the operation cannot be automated, retain a ready-to-submit prompt, reference files and their intended use; report what was not submitted. [Upstream image-import route](https://github.com/google-labs-code/stitch-skills/blob/0337446dadde6f8c94210444e2aa9d546126480f/plugins/stitch-design/skills/upload-to-stitch/SKILL.md)
+
+Use the request's page/state count and budget. Keep already selected directions and unchanged requirements. A user's selection without a requested modification does not require another generation or revision. Tool choice itself grants no additional publication, purchase or production-edit authority.
+
+## Observe writes and recover uncertain outcomes
+
+Before a write, retain the target project, selected screen identities, submitted input and known before state. Read the tool result, including MCP `isError`, service messages and available structured content. Transport success is not design success. Preserve returned project/session/screen identifiers, relevant progress and every produced design; suggestions in a response are not authorization to launch more work.
+
+Generation and visual-edit calls may keep running after a timeout or connection loss. Do not automatically resubmit an uncertain write. Retain and follow any live host operation handle. When an output screen is known, refresh it; when none was returned, inspect the target project's screens to locate the actual output. An empty or unchanged read alone does not prove the write never ran. Use the current tool's recovery instructions: the published generation/variant guidance describes reads at 30-second intervals, bounded to ten checks. If that bound ends without a resolved outcome, report it as unresolved, retain the recovery identifiers and continue independent work. Do not turn a monitoring timeout into a new generation. [Tool recovery descriptions](https://github.com/google-labs-code/stitch-sdk/blob/575a9fb6319bd9d1ce8175e4a89e5958e024bbfd/packages/sdk/generated/tools-manifest.json)
+
+For a confirmed rejection before submission, fix the specific cause and retry only if safe, within the task budget and allowed by the live tool. Keep technical recovery distinct from a requested visual revision; stop repeating a failed technical attempt. A retry allowance does not override Stitch's no-resubmission guidance for uncertain generation/edit outcomes.
+
+## Retrieve, inspect and preserve real outputs
+
+Refresh edited screens before judging the result. Some clients cache screen data; an old URL or success message does not prove that the requested change persisted. The published result shape can contain `outputComponents[].design.screens[]`; `get_screen` returns screen data directly. Inspect the actual result shape, preserve every returned design and use returned `htmlCode.downloadUrl` and `screenshot.downloadUrl` when present. These are URLs, not already saved files. Use available download capabilities to materialize the exact files and verify the saved content. [Screen result handling](https://github.com/google-labs-code/stitch-sdk/blob/575a9fb6319bd9d1ce8175e4a89e5958e024bbfd/packages/sdk/generated/src/screen.ts), [SDK resource access](https://github.com/google-labs-code/stitch-sdk/blob/575a9fb6319bd9d1ce8175e4a89e5958e024bbfd/README.md)
+
+Keep original Stitch files, actual submitted prompts, reference origins/purpose and needed before/after versions. Record stable project links when actually available; do not manufacture share links or publish a project to obtain one. Use transient download credentials only for retrieval and redact them from saved transport records. Preserve original generation dimensions and explain any difference from the requested comparison conditions. View current screenshots and render current HTML when relevant; inspect completeness, clipping, readability, assets, hit regions and supported interaction against the task's requirements. Do not remove information or shrink an entire design merely to make a comparison look cleaner.
+
+For an edit, verify both the requested change and the features that should have stayed. Save subsequent manual or agent code repairs as distinct revisions, not as untouched Stitch output. HTML can be editable without being a native design-node document. Report screenshot-only delivery or missing exports honestly. A requested downstream conversion is separate work: preserve the Stitch original and open/check the converted result before claiming that format. Another design tool is not a prerequisite or substitute for Stitch generation.
+
+Keep optional model/mode and usage observations task-local when they help. The host model and Stitch service model are different; do not infer the latter from the former. Unknown usage remains unknown, and an account-wide quota change is not evidence of the cost of one screen. Product defects, user preference, source editability, adoption and production verification remain separate conclusions. Use [adoption and Context ownership](adoption.md) when applying an authorized adoption.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "project-tiny-context-harness",
-  "version": "0.12.0",
+  "version": "0.12.1",
   "description": "Durable project facts and a short development contract for coding agents.",
   "license": "MIT",
   "author": "Seven128",

package/source-mappings.yaml

@@ -5,6 +5,9 @@ source_mappings:
   - source: ".codex/ty-context-managed/minimal_tools/context_rules.json"
     target: "packages/ty-context/assets/tools/context_rules.json"
     mode: "copy-file"
+  - source: ".codex/ty-context-managed/skills/design-resource"
+    target: "packages/ty-context/assets/skills/design-resource"
+    mode: "copy-tree"
   - source: "README.md"
     target: "packages/ty-context/README.md"
     mode: "copy-file"