A component in the old files does not prove the site had that feature

When refactoring an old website, it is easy to mistake a file inventory for a feature inventory. A file named SideFunctionBar.vue really does exist, and it really does contain filter buttons for React, Vue, and Vanilla JS. Those two facts only prove that someone wrote the component into the project. They do not directly prove that users of the original site ever saw or operated that interface.

For a feature to be established, you need at least a traceable path from a public entry point to where it is actually mounted, then to a user action and a visible result. A file’s existence is the starting point for gathering evidence, not the conclusion that a feature exists.

References to the site’s current implementation below describe the state recorded in the original note dated October 2, 2026.

Separate the kinds of evidence behind “it exists”

Evidence	What it establishes	What it does not yet establish
The file exists	The project retained this code	A page ever loaded or displayed it
The component contains complete logic	Its author wrote a possible behavior path	That path connects to an entry point
A store, data, or styles exist	Supporting state and presentation may have been prepared	Users can trigger it
A route or parent component imports it	Execution has a way to reach the component	Every interaction and state change actually works
The result is visible in HTML or a browser	The feature was rendered or executed in the environment inspected	All historical versions and deployment environments behave the same way

These layers cannot stand in for one another. Finding a component file is enough to list it as an “implementation candidate to investigate.” To describe it as a feature of the original site, you still need evidence of its entry point and behavior.

Tracing the project-filtering component

The old Vue project in this case contained SideFunctionBar.vue. It had three buttons for switching between React, Vue, and Vanilla JS, and used filterKeywords to change the project filter. Reading the file alone could easily leave the impression that the original site had a technology filter bar.

Following the application entry point revealed this chain instead:

App.vue → AppShell.vue → router-view → WorkViews.vue

AppShell.vue handled the shared shell and route content without placing SideFunctionBar.vue in the shell. WorkViews.vue did not import the component either. The work page did read filterKeywords and had a function for matching project tags. Its template, however, displayed a switch between two project categories, websites/systems and content/visuals, rather than those three technology buttons.

Two things need to be kept separate here:

• The filter state and matching logic existed, showing that the project retained traces of that design direction.
• SideFunctionBar.vue was not connected to the application’s mounting chain, so this traceable entry point provided no evidence that users could operate it.

The more accurate label is: a residual implementation not verified through the inspected entry point, rather than an established public feature of the original site.

Preserve behavior that actually existed

The refactor therefore retained the project-category switch with a clear entry point. It did not also carry over the technology filter simply because that filter looked reasonable.

The Astro work page recorded here still rendered two native links pointing to #development and #design. A browser script read [data-work-type], used the hash to display the corresponding section, and synchronized aria-current. Technology tags in the project data could still appear on the cards, but they were project information, not another unverified filtering control.

This small distinction changes the result of a refactor. Looking only at the old files could have added a set of technology buttons to the new page. Checking the entry point and actual template showed that the behavior to restore was the project-category switch, not an expansion of an unmounted sidebar feature. The production-output check also specifically confirmed that the generated HTML did not bring the dormant sidebar’s data-filter controls back onto the page.

How to assess an old component

Follow this order rather than guessing the conclusion from the filename:

1. Find the public entry point first. Start with the route, page entry point, or application shell, and establish how readers reach the page containing the feature.
2. Trace imports and template mounting. Does the inspected entry point or a parent component reference the file? A reference from some other file in a folder does not by itself mean the component appears on a production page.
3. Trace events and state writes. A click handler, store, or filtering function inside a component does not prove there is an actual control that can trigger it. Find the complete path from a visible control to a state change.
4. Inspect output, not just source code. Check the initial HTML, build output, or actual browser view to confirm that the control appears and that its result really changes.
5. Distinguish the conclusions. An item might be mounted and operable, mounted with incomplete behavior, residual logic only, or unsupported by enough evidence. Do not describe all four states as “an existing feature.”

This order also applies to animation components, old navigation, apparently complete forms, and features that have left behind only data fields. However convincing a component name may sound, it cannot replace evidence of the connection between the component and an entry point.

What this investigation can prove

A repository can establish which code was retained, which import relationships can be traced, and which output the inspected environment produced. It cannot automatically establish that every historical deployment used the same code, or rule out experimental versions that were never committed to the repository.

The conclusion here is therefore limited to the application entry point and output that could be traced: SideFunctionBar.vue was not verified as an operable public feature of the original site. That is not a claim about every historical version, nor does it turn an unmounted component into a requirement that the new site must restore.

Refactoring is not a matter of moving every old file into a new framework. It means checking again which content and behaviors have evidence behind them. Establish the entry point and visible result before deciding which old code to retain. A filename alone does not turn code into a feature.