workbench-develop

# Develop with evidence Use the destination project's tools and conventions to complete the requested change. Do not redesign its harness as a side effect of ordinary product development. ## Find the real path Read local instructions, the code map, build/test definitions, and relevant implementation. Identify the user-visible outcome and the smallest meaningful verification. Follow actual call sites; do not assume a named file, visible mode, or debug flag exists because a similar project had it. Use the project's documented command and pinned environment. On Apple projects, honor the local boundary between Tuist project generation, fastlane workflows, and native Xcode/runtime tools when that boundary exists. On other platforms, use their established equivalents; Workbench does not require Tuist or fastlane. ## Change, run, observe Make a focused change through existing business logic. For user-facing behavior, run the actual product in isolated state and observe the expected content and interaction. Prefer native accessibility/DOM inspection, screenshots, logs, debugger stacks, and test artifacts over custom proxy commands. Refresh semantic references after navigation, scrolling, keyboard movement, or other layout changes. After an important action, verify the resulting state: an item actually moved, text actually changed, a modal actually closed, or saved data actually reopened. A successful tap/type response does not establish that the product changed. When input appears to do nothing, inspect the current screen and hierarchy before adding retries. Use another supported input primitive if it helps distinguish a driver problem from a product problem. Preserve that distinction in the result. Inspect a stack or runtime log when it can resolve uncertainty more directly than editing code. ## Verify with attributable evidence Run tests relevant to the changed behavior and the project's required checks. Use existing fixture and snapshot infrastructure for visual changes. Preserve original before/current/difference artifacts when available; keep baseline acceptance separate from producing a report. Record enough context to connect evidence to the change: source revision and dirty state, relevant input or artifact identity, toolchain, target device/browser, launch/run identity, and fixture or interaction. An executable hash alone may not identify changed resources. Reuse existing provenance mechanisms before adding one, and do not describe local metadata as an independent attestation. If a test fails, preserve the failure and determine whether the cause is the product, the test's assumptions, the driver, or the environment. Correct the relevant layer and rerun the affected check. Do not relax assertions, timeouts, or visual tolerances simply to obtain a pass. Keep aggregate results honest. If a composed pipeline failed and a focused rerun later passed, report both facts and whether relevant source or environment changed. Repeat unaffected checks only when changes or unresolved concerns justify it. ## Finish with the result Report what changed, what was observed, the commands/results, and useful artifact paths. Distinguish actual execution from a proposed command. State any acceptance boundary that matters: a screenshot does not establish touch ergonomics, a simulator does not establish physical hardware behavior, and an unsigned archive is not a distributable build. Stop when the requested behavior and necessary verification are complete. Follow the user's and project's delivery authorization; a successful local check does not expand it.