During the website work, the instruction was to remove video or VR menus when there was no material to connect. A visitor should not be offered a button that leads to an empty page or broken experience. Yet treating a file I have not found as material that definitely does not exist creates another mistake.
The shared guide records three states: confirmed, absent and pending. Absent and pending may both stay hidden from visitors, but they remain different in the work record. I have reimplemented that distinction in a small shareable CLI. It computes results from declared states; it does not inspect an entire website or discover its material.
A menu makes a promise about what follows the click
A video or virtual-tour label tells visitors that there is something behind the button. Leaving the label without a working package makes failure more visible than the explanation. Another original request removes information associated with an unavailable model-house connection. The decision was to match the visible offering to the material actually available, rather than fill every space in a template.
An item can be declared absent after the relevant material list or responsible decision has been checked. Waiting for an answer or searching another location is pending. Both can stay out of the current preview, but the next action differs. Recording only the hidden screen state loses the distinction between a settled omission and an outstanding question.
Display and readiness for release are separate questions
The original guide says to show confirmed material, remove absent material from the relevant presentation and hide pending material in a preview while blocking a production build. The new code isolates that state decision. Permission to inspect a preview is not the same as readiness to release the site.
A preview can let the maker continue improving the reading flow with known material. Pending items must remain in the work record until actual material is confirmed or a supported decision establishes that the item will not be provided. Changing pending to absent merely to pass a build discards the reason for the unresolved state. The program preserves that reason rather than automatically resolving it.
One state cannot stand in for every presentation surface
Hiding a facilities section on the home page need not remove a detailed information page. A photograph may be unfinished while a document is available. Conversely, a decorative image can exist while the executable VR package does not. The source guide keeps home sections and detailed menus separately declared because they have different roles.
When every child menu is hidden, a website implementation should also examine the parent group and sitemap. The shared CLI does not make those changes. It returns visible, declared_absent and pending IDs, along with a bounded build-gate result. Connecting that result to a real site requires code that understands the site’s menu hierarchy and material relationships. It is a small input contract, not a universal template installer.
Confirmed is still a declaration that needs evidence elsewhere
Writing confirmed does not prove that a file opens, its facts are correct or its use has been approved. This program trusts the supplied declaration when calculating a result. The actual material must therefore be checked before that declaration is made. Plans, project descriptions and generated decorative images each need more specific questions than a single status label can answer.
Absent also must not be read as a claim that a real facility or contractor does not exist. It describes the caller’s decision about material to present. Omitting a row because no usable information is available is different from writing a factual statement about the development itself. Losing that boundary can turn a quiet interface omission into an unsupported assertion.
What the shared CLI actually lets you inspect
The package contains new Python code, synthetic input, isolated checks and a usage guide. An invented example combines a confirmed plan, an absent video and a pending tour. Preview is allowed; release remains blocked with the tour still pending. The checks also cover invalid states, duplicate IDs and duplicate JSON keys. The twenty-four passing checks do not replay the original customer services.
A reader can explicitly map a different material schema into this contract and keep separate checks for actual files and release requirements. Changing a status rule means choosing a new responsibility, not simply renaming a field. The useful lesson is how to keep unfinished confirmation work visible even when its screen element is hidden. That record allows another maker or computer to continue from the same decision rather than reconstruct it from a missing menu.