A good doc does not prove that you were busy. It helps someone else be accurate.
A lot of student projects collect documentation the way old desks collect paper. There is a plan, then a newer plan, then a screenshot of the plan, then a heroic closeout that forgets which plan survived. The folder looks serious. The next person opens it and immediately becomes tired.
Documentation should be a lantern. It should cast enough light for the next worker to see the floor, the tools, and the edge of the hole. That means a project entrypoint, a current-state note, a scope boundary, a validation plan, and a record of decisions that actually changed the build. It does not mean a shrine to every thought the team has ever had.
The test is simple: can a future AI session read the docs and avoid asking the student where everything is? If not, the docs are decorative. A good entrypoint tells the reader what this project is, what exists now, what is in scope, what proof matters, and which files control the work. It points without bragging.
Keep docs alive by making them answer active questions. What changed? What is deferred? What can be safely claimed? What would require approval? If the document cannot help someone decide, build, verify, or hand off, it probably belongs in an archive, not the main path.