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

# Seed a separate test repo against a running app

> Run the explore agent on a schedule from your Momentic test repo, exploring a running app instead of a code diff.

<Warning>The explore agent is in beta and may change.</Warning>

Plenty of teams keep their Momentic tests in a repo of their own, separate from
the application they cover. When the app source is not in the same repo as your
tests, you can skip the diff entirely and have
[`momentic ai explore`](/docs/ai/explore) map the running app instead. Run it on a
schedule from the test repo and let it seed coverage.

This is the simpler of the two poly-repo setups: one repo, no cross-repo
checkout. If you want coverage tied to specific pull requests instead, see
[Explore a code diff into a separate test repo](/docs/guides/explore/poly-repo-diff).

## Run it

Build and start the app first and point the project's
[`baseUrl`](/docs/configuration/momentic-config) at it, since this is what the agent
explores. Then, from the test repo:

```bash theme={null}
cd /tests
npx momentic ai explore latest --no-code
```

[`explore latest`](/docs/ai/explore#seed-coverage-for-the-whole-app) maps the whole
product and seeds coverage for it instead of anchoring to a change.
[`--no-code`](/docs/cli-reference/momentic/commands/ai#explore) drops the agent's git
and filesystem access, which it would otherwise waste looking for application
source that is not in this repo; it grounds everything in the running app
through its browser session.

## Delivering the tests

Explore runs inside the test repo, so tests are written where git can see them
and the **On successful explore** setting in
[Settings > Explore](https://app.momentic.ai/settings/explore) behaves like any
single-repo run. Set it to `pull-request` to get a PR against the test repo. The
[CI guide](/docs/guides/explore/in-ci) covers the delivery options and a workflow you
can adapt to a scheduled trigger.

## Notes

* Explore never touches your application code. Its analysis is read-only with
  respect to the app.
* Because there is no diff, coverage grows as a baseline over the whole product
  rather than reacting to what just merged.