# What Happens If No Scroll-Driven Behavior Is Detected: AI Website Cloner Logic Explained
> Discover AI website cloner logic when no scroll driven behavior is detected. Learn how the system defaults to static or click/hover-driven classifications for accurate code generation.
- Repository: [JCodesMore/ai-website-cloner-template](https://github.com/JCodesMore/ai-website-cloner-template)
- Tags: internals
- Published: 2026-07-05
---
**If no scroll-driven behavior is detected during the inspection phase, the system defaults to classifying the component as either static (no interactivity) or click/hover-driven, ensuring the generated code matches the actual interaction model rather than forcing scroll-based animations.**
The JCodesMore/ai-website-cloner-template employs a rigorous inspection protocol to accurately categorize UI components by their interaction models. Understanding the fallback mechanism when scroll triggers are absent is critical for generating faithful reproductions of target websites, as misclassifying static elements as scroll-driven leads to unnecessary complexity and visual fidelity errors.
## The Inspection Decision Tree
The inspection process follows a strict sequential workflow defined in [`.opencode/commands/clone-website.md`](https://github.com/JCodesMore/ai-website-cloner-template/blob/main/.opencode/commands/clone-website.md) and [`docs/research/INSPECTION_GUIDE.md`](https://github.com/JCodesMore/ai-website-cloner-template/blob/main/docs/research/INSPECTION_GUIDE.md). This hierarchy prevents the "single most expensive mistake in cloning": building click-based UIs when the original uses scroll-driven interactions, or vice versa.
### Step-by-Step Detection Process
The system executes interaction detection in the following priority order:
1. **Scroll Test First**: The inspector loads the page and performs a gentle scroll without clicking anything. If elements change position, opacity, or styling during this scroll, the component is immediately flagged as **scroll-driven**.
2. **Fallback to Click/Hover**: If nothing changes during the scroll observation phase, the inspector proceeds to Step 3: testing click and hover interactions to determine if the component is **click-driven** or **hover-driven**.
3. **Static Classification**: If neither scroll nor click/hover triggers produce state changes, the component is documented as **static**.
According to the source documentation: "If nothing changes on scroll, start clicking interactive elements. Record click-driven changes." This explicit sequencing ensures that the absence of scroll behavior triggers an immediate pivot to alternative interaction models.
### Classification Outcomes
When no scroll-driven behavior is detected, the component spec is populated with one of two interaction models:
- **Static**: No state changes occur regardless of user interaction. The component renders identically in before and after states.
- **Click-driven** or **Hover-driven**: State changes only occur through explicit user actions like mouse clicks or hover events.
## Component Specification Format
The interaction model is explicitly documented in the component specification template found in [`docs/research/INSPECTION_GUIDE.md`](https://github.com/JCodesMore/ai-website-cloner-template/blob/main/docs/research/INSPECTION_GUIDE.md). Each component entry includes:
- **Interaction Model**: One of `static`, `click-driven`, `scroll-driven`, `hover-driven`, `time-driven`, or combinations
- **Trigger**: The exact mechanism (e.g., `click .btn-primary`, `hover .card`, or `none` for static)
- **Before/After States**: CSS snapshots capturing the visual state before and after the trigger
When no scroll-driven behavior is detected, the `Trigger` field reflects the actual mechanism found during click/hover testing, or is marked as `none` for static components.
## Code Examples
The following examples demonstrate how the system documents components when scroll-driven behavior is absent versus when it is present.
### Static Component (No Scroll-Driven Behavior Detected)
When scrolling produces no visual changes and no click interactions exist, the component is classified as static:
```typescript
/**
* Component: Header
* Interaction Model: static
* Trigger: none
* Before State: { background: "#ffffff", height: "80px", position: "relative" }
* After State: { background: "#ffffff", height: "80px", position: "relative" }
* Transition: none
* Dependencies: []
*/
export function Header() {
return (
Site Title
);
}
```
### Click-Driven Component (Fallback After No Scroll Change)
When scrolling reveals no changes but clicking reveals interactivity:
```typescript
/**
* Component: MobileMenu
* Interaction Model: click-driven
* Trigger: click .hamburger-button
* Before State: { transform: "translateX(100%)", opacity: 0 }
* After State: { transform: "translateX(0)", opacity: 1 }
* Transition: CSS transition (0.3s ease-out)
* Dependencies: []
*/
export function MobileMenu({ isOpen }: { isOpen: boolean }) {
return (
);
}
```
### Scroll-Driven Component (For Comparison)
When scroll-driven behavior is detected, the spec captures scroll-specific triggers:
```typescript
/**
* Component: StickyHeader
* Interaction Model: scroll-driven
* Trigger: IntersectionObserver rootMargin "-100px 0px 0px 0px"
* Before State: { background: "transparent", boxShadow: "none", height: "100px" }
* After State: { background: "#ffffff", boxShadow: "0 2px 10px rgba(0,0,0,0.1)", height: "70px" }
* Transition: CSS transition (0.3s ease)
* Dependencies: []
*/
export function StickyHeader() {
// Implementation uses IntersectionObserver or scroll listener
// to toggle classes based on scroll position
return (
{/* Header content */}
);
}
```
## Why Accurate Detection Matters
Misclassifying a static component as scroll-driven results in unnecessary JavaScript overhead, broken animations, and visual regression failures. The inspection guide explicitly warns against this: building the wrong interaction model creates "the single most expensive mistake in cloning."
By defaulting to static or click-driven classifications when no scroll-driven behavior is detected, the ai-website-cloner-template ensures:
- **Performance**: No unnecessary scroll listeners or IntersectionObservers are generated for static content
- **Accuracy**: The cloned website behavior matches the original exactly
- **Maintainability**: Component specs clearly document the actual interaction requirements
## Summary
- **Primary check**: The inspection protocol always tests for scroll-driven behavior first by observing visual changes during gentle scrolling.
- **Fallback logic**: If no scroll-driven behavior is detected, the system immediately pivots to testing clicks and hovers, classifying the component as either static or click/hover-driven.
- **Documentation**: The interaction model is explicitly recorded in the component specification, ensuring the code generator produces the correct implementation without scroll-based logic.
- **Source files**: This logic is implemented in [`.opencode/commands/clone-website.md`](https://github.com/JCodesMore/ai-website-cloner-template/blob/main/.opencode/commands/clone-website.md) (lines 86-88) and detailed in [`docs/research/INSPECTION_GUIDE.md`](https://github.com/JCodesMore/ai-website-cloner-template/blob/main/docs/research/INSPECTION_GUIDE.md).
## Frequently Asked Questions
### What triggers the fallback to static classification?
If the inspector scrolls through a page section and observes no visual changes—meaning no elements move, fade, resize, or change color—the component is not marked as scroll-driven. The system then proceeds to test for clicks and hovers. If those also produce no state changes, the component is classified as static with a trigger value of `none`.
### Can a component be both static and scroll-driven?
No. According to the inspection taxonomy in [`docs/research/INSPECTION_GUIDE.md`](https://github.com/JCodesMore/ai-website-cloner-template/blob/main/docs/research/INSPECTION_GUIDE.md), the interaction model is mutually exclusive at the detection level. However, some components may combine models (e.g., a sticky header that also responds to clicks), which is documented as a combination like "scroll-driven with click interaction" rather than "static."
### How does the code generator use the interaction model classification?
The AI code generator reads the `Interaction Model` field from the component specification to determine which React hooks and browser APIs to implement. A `static` classification results in a simple functional component with no event listeners, while `scroll-driven` triggers the inclusion of `IntersectionObserver` or scroll event handlers. This prevents the generator from mistakenly adding scroll logic to components that should remain static.
### What happens if the inspector cannot determine the trigger mechanism?
In edge cases where animations are subtle or triggers are unclear, the inspection guide instructs inspectors to capture both before and after states and note "trigger unclear – manual inspection required" in the documentation. This prevents incorrect classification while flagging the component for human review rather than defaulting to an arbitrary interaction model.