Publish the methods details that another analyst would otherwise have to invent. A reproducibility appendix changes an article's evidence when someone can use its inputs and rules to reconstruct the reported result, identify a disagreement and locate the choice responsible. A longer methods section alone does not establish that capability.
Retire a public demonstration by preserving its explanation and selected historical evidence while disabling the actions it used to perform. Keep the old reading address useful when the material still has value. Test the old action addresses directly: a removed button cannot establish that a reservation, submission or other write has stopped working.
An external change should trigger review when it can alter a task the integration promises to perform, invalidate a test assumption or introduce an unmapped dependency. A dependency register makes that decision explicit: it connects each dependency to the behavior it supports, the tests that exercise it and the condition for accepting a candidate release. A new version number starts the assessment; it does not determine the result.
Restoring an older tool handler is safe only for the records whose meaning that handler can still preserve. Before reopening writes or restarting workers, test the old code against records created by the new release. Keep unsupported records intact, give pending tasks an explicit disposition, and check that completed work cannot run again. A successful code rollback alone does not answer any of those questions.
Preserve the tool's recovery contract when a backend release changes its errors. An adapter can translate a new validation response into the established error code, retryability flag and correction field. Change the consumer contract only when the meaning of the failure has changed or the adapter cannot preserve it safely. A successful release check must establish what happens after the error, including whether another write is attempted.
Close the old tool to new tasks at the deprecation cutoff, then retain a version-bound completion path for drafts that already exist. Give that path an explicit deadline and a way to recover unfinished work. Removing a tool from discovery and ending support for its active drafts are different release decisions. Combining them can turn a routine replacement into a lost enquiry.
An overdue pending action needs reconciliation: compare its unfinished task record with a correlated final receipt and the resulting business state, then record a justified disposition. Pending means the local record has no final outcome. Age identifies a record to investigate; it cannot establish whether the action succeeded, failed or never left the application. Keep uncertainty visible when the available evidence cannot resolve it.
Keep a dependency in a reproduction when removing it stops the specific failure you are investigating. A smaller setup that crashes for a different reason has lost the evidence. The useful reduction preserves the task, expected answer and failure condition while removing services and fields that do not affect that condition.
Choose synthetic identifiers that remain visibly artificial when copied into a screen, export or log, and put notification delivery behind a separate local-only transport. A reserved email domain helps identify a fixture, which is a reusable test record. It does not establish that an application cannot send a message. The useful acceptance condition is more specific: an approved fixture produces the expected labelled envelope inside a test sink, while malformed fixtures and delivery settings are rejected before capture.
Prioritise tests at the point where an agent request gains access to a record, triggers a business action or sends data outside the application. A tool description can constrain a request, but the decisive controls belong where the server grants authority. Test those controls through the tool handler and through direct server requests that bypass it.