Claude Code modifies config/data files without reading consumer logic, causing recurring bugs

Description

When Claude Code modifies configuration or data files (e.g., navigation configs, route definitions, component registries), it consistently reads and edits the data file without reading the components/functions that consume that data. This causes recurring bugs that could be avoided by tracing the data flow before making changes.

Recurring Pattern

1. User asks to move/add an item in a config file (e.g., navigation.ts)
2. Claude reads the config file and makes the data change
3. Claude does NOT read the rendering logic that imports/consumes that config
4. The change introduces bugs (wrong active state, broken rendering, missing props)
5. User catches the bug, Claude fixes it — but the pattern repeats next time

Concrete Example

Task: Move "Page Builder" from inside "Layouts" section to its own section in sidebar navigation.

What Claude did:

• Read navigation.ts (the data)
• Created a new section { id: 'page-builder', items: PAGE_BUILDER_ITEMS, zone: 'secondary' } without collapsible: true
• Did NOT read DesignSystemClientLayout.tsx which renders sections differently based on collapsible prop

Result: Page Builder showed as visually "active" on every page because CollapsibleSection treats non-collapsible sections as always-visible/active.

What should have happened:

1. Read navigation.ts to understand the data structure
2. Grep for imports of DEMO_NAV_SECTIONS to find consumers
3. Read CollapsibleSection in DesignSystemClientLayout.tsx to understand how collapsible, zone, and active state work
4. Only then make the change with correct props

Impact

This pattern has occurred multiple times across sessions in a multi-package design system project. Each time:

• Type-check and lint pass (it's not a type error)
• The bug is a runtime/visual behavior issue
• User loses trust in "everything is green" claims

Suggestion

Before modifying any data/config file, Claude Code should:

1. Identify all files that import the module being changed (grep -r "import.*from.*<file>")
2. Read the consumer logic, especially conditionals and edge cases
3. Verify the change is compatible with how the data is consumed

This is especially important for declarative config files where the data shape determines rendering behavior (navigation configs, route definitions, theme configs, form field definitions, etc.).

Environment

• Claude Code with Opus 4.6 (1M context)
• TypeScript + React + Next.js project
• Multi-package design system (PageShell)