seed-verify-lynx-component

Lynx component verification

Verify one Lynx component in the current worktree along with its related documentation and runnable examples. The result is a record that separates what was directly confirmed in which environment from the unverified scope. seed-orchestrate-componentIn collaboration via , a verifier independent of the implementer confirms the basic scenario and the final result. The implementer's summary, API review, and task closure are not grounds for approval.

Apply the same required checks, acceptance criteria, evidence, and permission boundaries to GPT-6-Astra and GPT-5.6 Luna, Terra, and Sol. If model-specific supplementary instructions are needed, explicitly link the actual model and instruction bundle in the execution environment and confirm loading. Do not assume that instructions change based on a model's self-identification or a model switch alone.

Scope and boundaries

• Target one component at a time along with the requested scenarios and change surface. New components or full-equivalence claims include all related scenarios.
• Check the target path's package public exports, Recipes, documentation examples,examples/lynx-spa consumption paths, and only the necessary generated artifacts in read-only mode. Do not pass based solely on the existence of source files.
• For scenarios where React and Lynx claim the same user result, compare at the content level. Do not conflate results from the browser, native bundle, local Lynx runtime, and real devices with one another.
• The verifier does not modify component or documentation sources. Generating artifacts from existing builds and changing the state of owned sessions necessary for approved verification are permitted, but follow the repository's no-modification paths, generation procedures, and ownership rules. If a problem is found, report the cause and the scope of the fix.
• In collaboration, check the changed-version identification information and bundle handed over by the integration owner. If there are follow-up fixes, revert the affected items to 미확인. Verification division of labor and resourcesDetermine the operation owner for each shared server, host app, device, global overlay, and capture resource accordingly. The coordinator integrates and approves results and does not personally run every check.
• Do not arbitrarily terminate or revert existing servers, user sessions, or user changes. examples/lynx-spa Only the host owner may newly start, restart, or stop a server.

If the request is to write or modify documentation or examples, use seed-component's Lynx documentation branch. This skill applies starting from a runnable basic scenario, implements the remaining scope, and is also used for final verification.

Skills used together

Use only the skills needed for the verification purpose.

• seed-component's path lookup: Confirm actual packages, Recipes, public exports, documentation examples, and SPA consumption paths
• seed-component's API comparison: Confirm differences between React and Lynx in public APIs, state, events, and accessibility
• lynx-api-docs: Confirm Lynx element, layout, and API behavior
• lynx-check-css-support: Confirm CSS property and value backends and Engine versions
• lynx-devtool: CLI usage for online verification and collection of DOM, layout, console, and screenshot evidence
• analyze-video-frames: Time-axis analysis of transition and first rendering

For the common execution procedure and runtime evidence collection, read and follow the verification runbook. agent-lynx The CLI is the default path, and DevTool MCP supplements only when available. If neither is available, perform only the static checks possible and leave native results as 환경 차단.

For online verification, even standalone execution first reads session ownership and Card lifetime. It applies when multiple agents or worktrees use the same app/client or when continuing open → reload → snapshot/evaluate, and to page cleanup. The same PlayLynx client is serialized with a shared lock from Card creation to removal confirmation. Fix the exact client/session pair and bundle URL of the Card opened this time in the occupancy record, and do not assume a new client will be created or arbitrarily occupy an existing Card.

Verification flow

1. Fix the target, consumption path, and required environment

Record only the target component, scenario, expected result, and the environment required for this change. Use the read-only path lookup of seed-componentonly when the target path or public consumption path is unclear, and use read-only API comparison only when a public API difference is the verification target.

• Document URL, React example and Lynx example ID, SPA query ID lynx/<component>/<scenario>
• The actual consumption path from the package public export to the example
• The changed user result and expected result
• Required/optional environment and handling when unavailable

Receive the original request, reference screen, and scenario directly and fix the approval conditions with observable result determination. Do not reverse-engineer expected results from the implementer's support list or completion summary. Distinguish between passing the default scene and passing the entire requested scope.

For work where only wording or code exposure changed, check the content, links, and format, and use a browser only when the rendering of the document page changed. For work that newly claims native behavior or changes execution results, run examples/lynx-spain the local Lynx runtime or the actual host app. If you change a path that depends on the host's page URL, such as PlayLynx's query selection, verify directly in that host.

If new components, public packages, Registry, or generated artifacts are included, or if native behavior or bundle execution results change, record the version and the pre-change baseline result separately from the current result according to the runbook's pre-checks. If there is no baseline result, leave it as 미확인. Do not include docs build, manifest, or static serve as prerequisites or final obligations for the default native scene.

2. Check React↔Lynx scenarios and SPA selection correspondence

For new scenarios, user result changes, and full equivalence requests, compare the React and Lynx documents and examples. For local changes to a single already-known scenario, compare only the corresponding file. Do not judge equivalence based solely on whether the titles are the same.

Item	React	Lynx / SPA	Verdict	Evidence
Document section·example ID	Title·order·logical ID	lynx/<component>/<scenario>	Same·converted·unsupported	MDX·example entry·SPA list
User result	asset·frame·initial state·auxiliary elements	Corresponding value	Same·converted·unsupported	package import·JSX·runtime
Input·transition	click·callback·intermediate·final state	bindtap·public callback·corresponding state	Same·Lynx-style conversion·unsupported	handler·runtime
Screen shell	AppScreen·AppBar·bottom CTA	native layout·bottom CTA	Same·converted·unsupported	SPA runtime

The verdict is left as one of 동일 지원, Lynx식 변환, 미지원 . 미지원does not pretend to execute and records limitations and alternatives in the document.

In an SPA opened without a query, document examples are selected in the order 홈 → 문서 예제 → 컴포넌트 → 시나리오 . example=lynx/<component>/<scenario> For direct entry, after loading, verify the exact source paths of the target scene and screen. If the query is not applied and the home screen keeps showing, do not treat it as a pass. If SPA entry·navigation was changed, also verify the error screen for a nonexistent ID and 컴포넌트 목록 → 홈 going back.

3. Verify public consumption paths and bundle connections

The package public exports, Registry, doc-gen, example entries, or bundles included in this change must point to the same component·scenario. Verify connections only when necessary.

package public export → SPA example import → lynx/<component>/<scenario> → main.lynx.bundle?example=…

Verify that the public name·logical ID·example import·SPA list·executed query match. Verify Registry·document index·manifest only when actually changing that surface or validating the document infrastructure. Do not guess bundle filenames·URLs·artifact paths; use the actual main.lynx.bundle URL from the SPA development server log.

4. Execution and evidence collection

Select only the verification runbook items that match the changed surface and required environment. The default native path is to open examples/lynx-spaand select a document example, or to enter directly with the example query. For bundle URL·deep link·new client/session identification·going back·nonexistent ID verification, follow the order in the runbook.

For code·public example·Registry·artifact changes, follow the automated verification in the common checklist. Also include type·regression·generation checks for document consumption paths affected by the change. Excluding the full docs build does not mean exemption from this check. If the required checks pass, repeat or broaden the checks only when there is a new change·failure·unresolved concern.

When the MDX·code tabs·QR·Web preview·docs build pipeline of the static document itself is changed, add document infrastructure verification. This condition is neither a prerequisite for native component verification nor a final obligation for a simple component change.

Even if session IDs differ, the same host process, window, global overlay, and capture resources are manipulated in order by their owners. The next scene navigates within the existing Card or reloads. Closing only the menu or overlay is not treated as Card cleanup, and after the last scene, removal of the owning session and release of the lock are also verified. Do not claim actual Lynx results based only on a browser preview.

5. Visual Equivalence Pass Conditions

For React and Lynx examples that claim the same user result, the visual equivalence determination in the verification runbookis applied. Viewport, frame, interaction, and asset evidence and pass conditions follow that item.

Determination and Reporting

Assign only one of the following statuses to each scenario and environment.

Status	Meaning
Pass	The expected result was directly confirmed in that environment
Fail	The difference between the expected result and the actual result was reproduced
Environment blocked	Verification could not be started because of tools, versions, addresses, or network
Unverified	Verification could have been performed but has not yet been run

Public consumption path connections and execution environments are separated into distinct tables. Only the required environments determined before verification begins are reflected in overall completion.

• If all required items are 통과, then overall 완료다.
• If the required items include 실패, then overall 실패다.
• If the required items include 환경 차단 or 미확인, then overall 미완료다.
• For optional environments, 환경 차단 or 미확인does not block the overall result but is recorded in the report.

The final report includes the target component and scenario, the React↔Lynx correspondence and public consumption path, the expected and actual results for each environment, the actual bundle URL and query, client, session, screenshot, console, and layout evidence (if used), the reproduction steps and scope of fixes for findings, and unverified environments with the exact reason for blockage.

When handing off to another owner, hand off briefly in the order 변경본 식별자 → 실행 명령/시나리오 → 판정과 기대·실제 결과 → 증거 → 실패 원천·영향 범위 . Only the lifetime owner cleans up the server, browser, and DevTool session that they started directly, and evidence referenced in the handoff is preserved at a path the recipient can read.