Show the next maintainer which file produces the visible result
A handover can contain all the files and still leave the successor editing the wrong one. If the site generates its styles from source, a change made only to the generated output may disappear at the next build.
This fictional example concerns an approved colour change to a service-information panel. The colour values have already been selected and reviewed for their intended use. The exercise is about reproducing that approved change through the project's build, not choosing a new visual identity or claiming that one colour check establishes accessibility.
Separate the source from its output
The project contains a source token named information-panel-background and a generated stylesheet used by the website. The delivery folder includes both, but the first handover note only says to change the panel colour in the stylesheet.
Successor Maia edits the generated file. The panel looks correct in her local view. She then runs the documented build to prepare the next release. The generated file is recreated from the unchanged source token, and the old value returns.
The evidence identifies a specific relationship:
| Item | Before the attempted handover | After the build |
|---|---|---|
| Approved source token | Old value | Old value |
| Generated stylesheet edited by Maia | New value | Recreated with old value |
| Rendered panel | Looks correct before rebuilding | Returns to the old value |
The build has not randomly lost the change. It has reproduced the source it was given. Editing more generated files would leave the underlying problem intact.
Correct the maintenance instruction
The maintainer identifies the supported source token and its build path. Maia changes that token to the approved value, leaves the generated file to the build and runs the documented process again.
The resulting stylesheet now contains the intended value, and the panel renders accordingly. The record identifies the source revision and build command used. An independently generated output can be compared with the delivered artifact rather than treated as an unexplained file from the original developer's machine.
The handover note is revised to name the source file, the relevant token, the build step and the result to inspect. It also explains that the generated stylesheet should not be the normal editing surface for this change.
Reproduce the task as the successor
The acceptance exercise is not complete when the original developer demonstrates it once. Maia starts from the agreed source revision in a clean working copy, uses the documented environment and performs the approved token change herself.
Her build produces the intended panel style. A separate warning component, which uses a different approved token, remains unchanged. The text and link inside the information panel also remain unchanged. The exercise does not apply a broad search-and-replace to every occurrence of a similar colour.
The team checks the panel in the relevant layouts and interaction states, retaining the approved contrast and focus requirements. If the source token is shared elsewhere, those uses must be identified and reviewed before treating the change as local.
Keep content approval separate from build authority
The person who approves a visual value may not be the person who can publish it. The handover should identify both responsibilities. An editor can prepare an approved change without automatically gaining authority to deploy a release.
This example stops at a reproducible reviewed artifact. The organisation's release process determines when and how that artifact becomes public. A successful local build is not evidence of production publication or recovery capability.
The same distinction applies to rollback. Retaining an earlier generated file does not by itself establish how to restore the corresponding source, dependencies and application state. Recovery needs the scope appropriate to the actual system.
Write instructions around a real maintenance task
A useful technical handover identifies the authoritative source, required environment, build and inspection steps, publishing authority and known limits. It should give the next person a task they can complete and a result they can recognise.
For this project, the decisive evidence is Maia's clean reproduction of the approved panel change. The delivery is no longer dependent on remembering that a particular output file will be overwritten. The maintenance route is explicit and tested within the example's boundaries.
Use a representative content or interface change when planning maintenance and takeover. If your team cannot tell which file produces the page they see, bring that uncertainty to the project discussion before assuming that a folder of code is a finished handover.