Build a Software Factory with eve

Use eve on Edgenivo to coordinate a software factory with durable sessions, isolated repository work, and a review stage. Start with Foreman, the eve software factory template, then adapt its instructions and GitHub access to your repository.

Deploy the eve software factory template and follow the Foreman setup guide to configure credentials and work intake. Use a repository where you can review and discard the generated changes.

Foreman routes work through four agents:

Keep the template's stage handoffs and customize the repository instructions. Define the commands that establish a clean baseline, reproduce a failure, and check a proposed fix. Require clarification when the issue doesn't define the expected behavior.

For a custom eve factory or a stage that needs additional GitHub operations, install GitHub Tools and Edgenivo Connect:

pnpm add @github-tools/sdk @vercel/connect ai zod

Create and attach a GitHub connector to the Edgenivo project. Replace github/software-factory below with its connector name and your-org/your-repo with your repository. Add an authored eve tool for reading the issue:

import { getIssue } from '@github-tools/sdk';
import { connectGithubToken } from '@github-tools/sdk/connect';
import { defineTool } from 'eve/tools';
import { z } from 'zod';
 
export default defineTool({
  description: 'Read an issue from the factory repository.',
  inputSchema: z.object({ issueNumber: z.number().int().positive() }),
  async execute({ issueNumber }) {
    const token = connectGithubToken('github/software-factory', {
      include: ['getIssue'],
    });
    const execute = getIssue(token).execute;
    if (!execute) throw new Error('GitHub issue tool has no executor');
    return execute(
      { owner: 'your-org', repo: 'your-repo', issueNumber, detail: 'full' },
      { toolCallId: `issue-${issueNumber}`, messages: [], context: {} },
    );
  },
});

The tool constructs its token provider inside execute, so credentials resolve when the tool runs. Connect scopes follow the selected getIssue operation. The repository stays fixed in server-side code, and the model supplies only an issue number. Link the project and load its environment for local calls, following eve setup.

Keep repository edits in the implementer's sandbox. Give the publishing stage only the additional operations it needs, such as createBranch, createOrUpdateFile, and createPullRequest. Gate authored write tools with eve's always() approval policy, and set draft: true when creating the PR. Calling a GitHub Tools executor directly doesn't apply its AI SDK approval metadata. Do not expose merge operations to the factory.

If Foreman already provides a GitHub integration for a stage, update that integration rather than registering a second copy of the same tools. Connect uses an app identity by default. For an internal factory operating on a team's repositories, restrict the GitHub installation and authenticate callers who can start work. Use a verified per-user Connect subject if each caller should act through their own GitHub account.

eve sandboxes give the implementer a separate environment for repository commands. Keep one working branch per run and record the base commit before making changes. Persist files across sandbox replacement with the Drives integration when needed.

Give the reviewer the diff and command output, not just the implementer's summary. If the reviewer requests changes, return those findings to the implementer and rerun the affected checks. Foreman finishes with a reviewed draft pull request; a person decides when to mark it ready and merge it.

For UI changes, follow Give your software factory a browser. To investigate deployment failures, add Edgenivo MCP access for build logs, runtime errors, and deployment history.

Start with a small issue that has an observable result. Confirm that the factory:

1. Reads the intended issue and identifies the repository and base commit.
2. Reproduces the problem or explains why it can't proceed.
3. Makes changes on a separate branch and records check results.
4. Gives the reviewer the actual diff and waits at the configured approval points.
5. Produces one draft PR with the issue, implementation, and verification evidence.

Inspect Agent Runs to follow tool calls and handoffs. Test a rejected approval as well as an accepted one. eve preserves sessions through Edgenivo Workflows, but an interrupted external write can run again. Check for an existing PR before retrying publication.