> ## Documentation Index
> Fetch the complete documentation index at: https://aidocs.ethanbragdon.icu/llms.txt
> Use this file to discover all available pages before exploring further.

# Modify Existing Projects

> Use FORGE safely against an existing codebase by preserving public interfaces, repository patterns, validation commands, and source revision.

# Modify existing projects

FORGE can be more valuable on an existing product than on a greenfield project—but only when it understands what must be preserved.

## Prepare the codebase

Before starting the build:

* connect or provide the correct repository/project snapshot
* identify the branch or revision
* include architecture or contribution docs when relevant
* identify protected public interfaces
* identify the normal build/test commands
* describe any migration constraints

## Ask FORGE to inspect before changing

For cross-file work, repository intelligence should locate the existing pattern and likely change surface before generation begins.

A strong request sounds like:

```text theme={null}
Add incident timeline filtering to the existing admin panel.
Preserve the current API route names and user-role checks.
Inspect the existing incident components and adminFetch wrapper before changing files.
Run the existing strict TypeScript build afterward.
```

## Preserve conventions

Existing projects often contain conventions that matter more than a generic best practice:

* API wrappers
* error handling
* component architecture
* naming
* environment/config loading
* database access patterns
* test helpers

Prefer consistency unless the task explicitly authorizes a refactor.

## Minimize change surface

A focused feature should not cause unrelated rewrites. The build plan should identify which files are expected to change and explain why when the change expands beyond that surface.

## Validate against the repository

Use the project's real supported validators where possible. A generic syntax check is not a substitute for the repository's own strict build or test suite.

## Source drift

If the repository changes materially after the build starts, refresh context and create a new build against the updated revision rather than assuming the existing artifact contains those changes.

<Warning>
  Review generated migrations, authentication changes, billing changes, infrastructure changes, and destructive data operations especially carefully before deployment.
</Warning>