Answers and explanations · Test behavior and prepare a build

A. Read and run the checks

Record the actual output rather than copying the package's historical QA count. Typecheck supports the static-contract claim. Reference tests support the particular rules and interactions asserted by their files. Build proves the configured entries can be transformed, not that a host serves every route correctly. Preview observations add browser evidence only if you actually opened and exercised the built pages. Learner capstone failures are separate from the completed-reference suite.

B. Repair a weak test

After a save click, assert that the named save button has aria-pressed='true', or that the saved-screen result contains that event. These observations remain meaningful if internal state representation changes. Use userEvent.setup and await the click. Await findByRole for asynchronous content rather than sleeping a fixed second. A simulated DOM does not certify layout, screen-reader announcements, browser autofill, touch targets or actual history behavior in the deployed host.

C. Transfer

A useful release note names the tested runtime, install/start/check/build/preview commands, the exact four verified journeys, and three unverified acceptance tasks such as mobile reflow, screen-reader behavior and a target-host subdirectory refresh. A known limitation might be browser-local preferences without multi-tab synchronization. Recovery can mean reverting to the saved source copy and reinstalling from its lockfile, or removing only the course preference key if deliberately corrupted during testing. The regression test should fail before the bug fix and pass afterward; preserve both outcomes so the assertion's value is demonstrated.