Vibecode OutFriend

You are building a lean indie version of OutFriend.

Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt.

===== README.md =====
# OutFriend indie build

## Goal

Build the smallest trustworthy replacement for the core OutFriend workflow for one developer or a tiny team.

## Scope

Pass a sample of your sent mail to a model as voice reference, draft one email per CSV row, queue them through the Gmail API on a throttle, and halt the follow-ups on any reply.

## Quick start

1. Install the documented dependencies.
2. Copy `.env.example` to `.env`.
3. Run the development command chosen during implementation.
4. Complete the acceptance checks in `BUILD_PLAN.md`.

## Honest limits

This build deliberately does not replace:
- reply detection that is thread-based rather than naive, so out-of-office replies do not count as interest and a reply from a different address still stops the sequence
- verification and suppression, meaning unverified, bounced and opted-out addresses filtered before anything queues
- a review surface where every draft is readable and editable before it goes, instead of trusting a script with your inbox
- lead generation, which the paid tiers include and your CSV does not
- the Google OAuth verification process, which you will meet the moment you want this on more than your own account

If those capabilities are essential, use Gmail API instead of pretending the gap is solved.

===== AGENTS.md =====
# Agent instructions

- Optimize for a working, understandable weekend build.
- Prefer the fewest moving parts that satisfy the brief.
- Do not invent cryptography, security guarantees, APIs, or compliance claims.
- Keep secrets out of source control and logs.
- Add focused tests for destructive, security-sensitive, and data-loss paths.
- Run the project checks before declaring the build complete.
- Record any deliberate shortcut in the README under "Tradeoffs".

===== BUILD_PLAN.md =====
# Build plan

## Original build brief

Build me a local cold email sender that drafts in my voice and sends from my own Gmail, to replace OutFriend. Requirements:

- Node 22, TypeScript, SQLite via better-sqlite3, googleapis for Gmail, node-cron for the
  schedule. CLI only. No accounts, no telemetry, OAuth token and API keys in .env.
- `mail auth` runs the Gmail OAuth device flow once and stores the refresh token locally.
  Scopes: gmail.send, gmail.readonly.
- `mail voice` pulls my last 200 sent messages, strips quoted replies and signatures, and
  saves 20 of the shortest complete ones to voice.md as the style reference.
- leads.csv holds email, first name, company and one context column. `mail draft` writes
  one email per row using voice.md plus the context column, saves each as status=draft,
  and refuses to draft for any address already in suppression.txt.
- `mail review` prints drafts one at a time in the terminal and takes approve, edit or
  skip. Nothing sends without an approve. This gate is not optional.
- `mail send` delivers approved drafts through the Gmail API inside a send window from
  config.json, with a daily cap and a random 30 to 180 second gap between sends.
- Every 30 minutes, `mail watch` polls threads for inbound messages. Any reply sets the
  lead to replied and cancels its remaining follow-ups. Treat an auto-reply as a stop
  too, and never as interest.
- Follow-ups are two fixed templates at day 4 and day 10 in the same thread, cancelled by
  any reply or bounce. Parse bounce DSNs and write those addresses to suppression.txt.
- Out of scope: lead sourcing, email verification, inbox warmup, and sending from any
  address that is not my own connected Gmail.
- README: OAuth setup, the send window config, and a plain warning to read CAN-SPAM and
  GDPR before the first campaign.

## Required capabilities

- a Google Cloud project with Gmail API access and OAuth consent configured
- an OpenAI or Anthropic API key
- a leads CSV you sourced yourself
- a scheduler that survives your laptop sleeping
- your own read of CAN-SPAM and GDPR before you send anything

## Delivery order

1. Scaffold the smallest runnable application and document its commands.
2. Implement the primary data model and core workflow.
3. Add validation, safe failure states, and persistence.
4. Cover the critical path with automated tests.
5. Exercise a clean install from the README and fix every missing step.

## Done when

- A new user can go from clone to first successful workflow using only the README.
- The core workflow works without paid infrastructure unless the brief requires it.
- Tests cover the highest-risk behavior.
- Known limitations are explicit rather than hidden.

===== .env.example =====
# Copy to .env and document every variable when it is introduced.
# Never put real credentials in this file.

APP_ENV=development
# Add only values required by the selected implementation.

You are building a lean indie version of OutFriend.

Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt.

===== README.md =====
# OutFriend indie build

## Goal

Build the smallest trustworthy replacement for the core OutFriend workflow for one developer or a tiny team.

## Scope

Pass a sample of your sent mail to a model as voice reference, draft one email per CSV row, queue them through the Gmail API on a throttle, and halt the follow-ups on any reply.

## Quick start

1. Install the documented dependencies.
2. Copy `.env.example` to `.env`.
3. Run the development command chosen during implementation.
4. Complete the acceptance checks in `BUILD_PLAN.md`.

## Honest limits

This build deliberately does not replace:
- reply detection that is thread-based rather than naive, so out-of-office replies do not count as interest and a reply from a different address still stops the sequence
- verification and suppression, meaning unverified, bounced and opted-out addresses filtered before anything queues
- a review surface where every draft is readable and editable before it goes, instead of trusting a script with your inbox
- lead generation, which the paid tiers include and your CSV does not
- the Google OAuth verification process, which you will meet the moment you want this on more than your own account

If those capabilities are essential, use Gmail API instead of pretending the gap is solved.

===== AGENTS.md =====
# Agent instructions

- Optimize for a working, understandable weekend build.
- Prefer the fewest moving parts that satisfy the brief.
- Do not invent cryptography, security guarantees, APIs, or compliance claims.
- Keep secrets out of source control and logs.
- Add focused tests for destructive, security-sensitive, and data-loss paths.
- Run the project checks before declaring the build complete.
- Record any deliberate shortcut in the README under "Tradeoffs".

===== BUILD_PLAN.md =====
# Build plan

## Original build brief

Build me a local cold email sender that drafts in my voice and sends from my own Gmail, to replace OutFriend. Requirements:

- Node 22, TypeScript, SQLite via better-sqlite3, googleapis for Gmail, node-cron for the
  schedule. CLI only. No accounts, no telemetry, OAuth token and API keys in .env.
- `mail auth` runs the Gmail OAuth device flow once and stores the refresh token locally.
  Scopes: gmail.send, gmail.readonly.
- `mail voice` pulls my last 200 sent messages, strips quoted replies and signatures, and
  saves 20 of the shortest complete ones to voice.md as the style reference.
- leads.csv holds email, first name, company and one context column. `mail draft` writes
  one email per row using voice.md plus the context column, saves each as status=draft,
  and refuses to draft for any address already in suppression.txt.
- `mail review` prints drafts one at a time in the terminal and takes approve, edit or
  skip. Nothing sends without an approve. This gate is not optional.
- `mail send` delivers approved drafts through the Gmail API inside a send window from
  config.json, with a daily cap and a random 30 to 180 second gap between sends.
- Every 30 minutes, `mail watch` polls threads for inbound messages. Any reply sets the
  lead to replied and cancels its remaining follow-ups. Treat an auto-reply as a stop
  too, and never as interest.
- Follow-ups are two fixed templates at day 4 and day 10 in the same thread, cancelled by
  any reply or bounce. Parse bounce DSNs and write those addresses to suppression.txt.
- Out of scope: lead sourcing, email verification, inbox warmup, and sending from any
  address that is not my own connected Gmail.
- README: OAuth setup, the send window config, and a plain warning to read CAN-SPAM and
  GDPR before the first campaign.

## Required capabilities

- a Google Cloud project with Gmail API access and OAuth consent configured
- an OpenAI or Anthropic API key
- a leads CSV you sourced yourself
- a scheduler that survives your laptop sleeping
- your own read of CAN-SPAM and GDPR before you send anything

## Delivery order

1. Scaffold the smallest runnable application and document its commands.
2. Implement the primary data model and core workflow.
3. Add validation, safe failure states, and persistence.
4. Cover the critical path with automated tests.
5. Exercise a clean install from the README and fix every missing step.

## Done when

- A new user can go from clone to first successful workflow using only the README.
- The core workflow works without paid infrastructure unless the brief requires it.
- Tests cover the highest-risk behavior.
- Known limitations are explicit rather than hidden.

===== .env.example =====
# Copy to .env and document every variable when it is introduced.
# Never put real credentials in this file.

APP_ENV=development
# Add only values required by the selected implementation.

You are building a production product version of OutFriend.

Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt.

===== PRODUCT.md =====
# OutFriend product brief

## Problem

This one is closer to buildable than most outreach tools, because OutFriend sends through your own Gmail rather than its own infrastructure. That removes the moat that usually saves this category: no warmup pools, no IP reputation, no deliverability engineering you cannot replicate. What is left is a Gmail OAuth integration, a voice sample you pass to a model, a scheduler with send windows and daily caps, and the one piece that is genuinely fiddly, watching threads so a sequence stops the instant someone replies. That is a weekend if you have written against the Gmail API before, and a long weekend if you have not.

## Product outcome

Pass a sample of your sent mail to a model as voice reference, draft one email per CSV row, queue them through the Gmail API on a throttle, and halt the follow-ups on any reply.

## Target user

A serious builder who needs a maintainable product foundation rather than a one-off demo.

## Required capabilities

- a Google Cloud project with Gmail API access and OAuth consent configured
- an OpenAI or Anthropic API key
- a leads CSV you sourced yourself
- a scheduler that survives your laptop sleeping
- your own read of CAN-SPAM and GDPR before you send anything

## Explicit non-goals for v1

- reply detection that is thread-based rather than naive, so out-of-office replies do not count as interest and a reply from a different address still stops the sequence
- verification and suppression, meaning unverified, bounced and opted-out addresses filtered before anything queues
- a review surface where every draft is readable and editable before it goes, instead of trusting a script with your inbox
- lead generation, which the paid tiers include and your CSV does not
- the Google OAuth verification process, which you will meet the moment you want this on more than your own account

## Success criteria

- The primary workflow is measurable end to end.
- Setup is reproducible in a clean environment.
- Failure, recovery, and support paths are documented.
- Product claims match what the implementation actually guarantees.

===== ARCHITECTURE.md =====
# Architecture

## Starting brief

Build me a local cold email sender that drafts in my voice and sends from my own Gmail, to replace OutFriend. Requirements:

- Node 22, TypeScript, SQLite via better-sqlite3, googleapis for Gmail, node-cron for the
  schedule. CLI only. No accounts, no telemetry, OAuth token and API keys in .env.
- `mail auth` runs the Gmail OAuth device flow once and stores the refresh token locally.
  Scopes: gmail.send, gmail.readonly.
- `mail voice` pulls my last 200 sent messages, strips quoted replies and signatures, and
  saves 20 of the shortest complete ones to voice.md as the style reference.
- leads.csv holds email, first name, company and one context column. `mail draft` writes
  one email per row using voice.md plus the context column, saves each as status=draft,
  and refuses to draft for any address already in suppression.txt.
- `mail review` prints drafts one at a time in the terminal and takes approve, edit or
  skip. Nothing sends without an approve. This gate is not optional.
- `mail send` delivers approved drafts through the Gmail API inside a send window from
  config.json, with a daily cap and a random 30 to 180 second gap between sends.
- Every 30 minutes, `mail watch` polls threads for inbound messages. Any reply sets the
  lead to replied and cancels its remaining follow-ups. Treat an auto-reply as a stop
  too, and never as interest.
- Follow-ups are two fixed templates at day 4 and day 10 in the same thread, cancelled by
  any reply or bounce. Parse bounce DSNs and write those addresses to suppression.txt.
- Out of scope: lead sourcing, email verification, inbox warmup, and sending from any
  address that is not my own connected Gmail.
- README: OAuth setup, the send window config, and a plain warning to read CAN-SPAM and
  GDPR before the first campaign.

## Boundaries

Separate the product into replaceable modules for interface, application logic, persistence, external integrations, and operational concerns. Keep domain logic independent from delivery frameworks and vendors.

## Production baseline

- Configuration: validated at startup with safe local defaults where possible.
- Security: least privilege, input validation, secret redaction, rate limits on abuse-prone paths, and no invented security primitives.
- Data: explicit schema and migrations, transactional writes where integrity matters, backup and restore instructions.
- Integrations: adapters around third-party providers, idempotent webhook or job processing, bounded retries, and timeouts.
- Observability: structured logs with request or operation IDs, an error-tracking hook, and health/readiness checks where a server exists.
- Quality: unit tests for domain rules, integration tests at module boundaries, and one end-to-end critical-path test.

## Decision records

For each major dependency, document why it was chosen, its failure mode, and how it can be replaced. Do not introduce infrastructure until a requirement justifies it.

===== AGENTS.md =====
# Agent instructions

- Read `PRODUCT.md` and `ARCHITECTURE.md` before changing code.
- Implement milestone by milestone; keep each change reviewable and leave the application runnable.
- Treat authentication, payments, encryption, imports, webhooks, and destructive actions as high-risk boundaries when present.
- Never invent cryptography or silently weaken a requirement to make a test pass.
- Use provider interfaces for external services and deterministic fakes in tests.
- Add migrations and rollback or recovery notes for persistent data changes.
- Log useful operational context without credentials, tokens, passwords, or personal data.
- Update documentation and run all checks before completing a milestone.

===== MILESTONES.md =====
# Delivery milestones

## M0 — Decisions and scaffold

- Confirm the runtime, persistence model, threat boundaries, and deployment target.
- Create a reproducible local environment and continuous checks.

## M1 — Core workflow

- Implement the smallest end-to-end product path with validation and tests.
- Keep integrations behind interfaces.

## M2 — Trust layer

- Add secure failure behavior, recovery paths, audit-relevant events, and data safeguards.
- Test abuse cases and destructive operations.

## M3 — Operability

- Add structured logs, error reporting hooks, health signals, backup/restore documentation, and deployment configuration.

## M4 — Release gate

- Run a clean-install test, critical-path end-to-end test, dependency review, and documented rollback exercise.
- Compare the shipped behavior with `PRODUCT.md` and publish remaining limitations.

===== OPERATIONS.md =====
# Operations

## Before release

- Validate configuration and secrets at startup.
- Define backup, restore, and rollback procedures and test them.
- Document logs, error tracking, health signals, and alert ownership.
- Set dependency update and vulnerability review expectations.

## Incident checklist

1. Contain the issue without destroying evidence or user data.
2. Record the timeline and affected scope.
3. Rotate exposed secrets and revoke compromised sessions or credentials.
4. Restore from a verified source when needed.
5. Document the root cause, remediation, and regression test.

## Launch constraint

Do not market omitted OutFriend capabilities as implemented. The v1 non-goals in `PRODUCT.md` remain user-visible limitations until they are deliberately delivered.

# OutFriend indie build

## Goal

Build the smallest trustworthy replacement for the core OutFriend workflow for one developer or a tiny team.

## Scope

Pass a sample of your sent mail to a model as voice reference, draft one email per CSV row, queue them through the Gmail API on a throttle, and halt the follow-ups on any reply.

## Quick start

1. Install the documented dependencies.
2. Copy `.env.example` to `.env`.
3. Run the development command chosen during implementation.
4. Complete the acceptance checks in `BUILD_PLAN.md`.

## Honest limits

This build deliberately does not replace:
- reply detection that is thread-based rather than naive, so out-of-office replies do not count as interest and a reply from a different address still stops the sequence
- verification and suppression, meaning unverified, bounced and opted-out addresses filtered before anything queues
- a review surface where every draft is readable and editable before it goes, instead of trusting a script with your inbox
- lead generation, which the paid tiers include and your CSV does not
- the Google OAuth verification process, which you will meet the moment you want this on more than your own account

If those capabilities are essential, use Gmail API instead of pretending the gap is solved.

# Agent instructions

- Optimize for a working, understandable weekend build.
- Prefer the fewest moving parts that satisfy the brief.
- Do not invent cryptography, security guarantees, APIs, or compliance claims.
- Keep secrets out of source control and logs.
- Add focused tests for destructive, security-sensitive, and data-loss paths.
- Run the project checks before declaring the build complete.
- Record any deliberate shortcut in the README under "Tradeoffs".

# Build plan

## Original build brief

Build me a local cold email sender that drafts in my voice and sends from my own Gmail, to replace OutFriend. Requirements:

- Node 22, TypeScript, SQLite via better-sqlite3, googleapis for Gmail, node-cron for the
  schedule. CLI only. No accounts, no telemetry, OAuth token and API keys in .env.
- `mail auth` runs the Gmail OAuth device flow once and stores the refresh token locally.
  Scopes: gmail.send, gmail.readonly.
- `mail voice` pulls my last 200 sent messages, strips quoted replies and signatures, and
  saves 20 of the shortest complete ones to voice.md as the style reference.
- leads.csv holds email, first name, company and one context column. `mail draft` writes
  one email per row using voice.md plus the context column, saves each as status=draft,
  and refuses to draft for any address already in suppression.txt.
- `mail review` prints drafts one at a time in the terminal and takes approve, edit or
  skip. Nothing sends without an approve. This gate is not optional.
- `mail send` delivers approved drafts through the Gmail API inside a send window from
  config.json, with a daily cap and a random 30 to 180 second gap between sends.
- Every 30 minutes, `mail watch` polls threads for inbound messages. Any reply sets the
  lead to replied and cancels its remaining follow-ups. Treat an auto-reply as a stop
  too, and never as interest.
- Follow-ups are two fixed templates at day 4 and day 10 in the same thread, cancelled by
  any reply or bounce. Parse bounce DSNs and write those addresses to suppression.txt.
- Out of scope: lead sourcing, email verification, inbox warmup, and sending from any
  address that is not my own connected Gmail.
- README: OAuth setup, the send window config, and a plain warning to read CAN-SPAM and
  GDPR before the first campaign.

## Required capabilities

- a Google Cloud project with Gmail API access and OAuth consent configured
- an OpenAI or Anthropic API key
- a leads CSV you sourced yourself
- a scheduler that survives your laptop sleeping
- your own read of CAN-SPAM and GDPR before you send anything

## Delivery order

1. Scaffold the smallest runnable application and document its commands.
2. Implement the primary data model and core workflow.
3. Add validation, safe failure states, and persistence.
4. Cover the critical path with automated tests.
5. Exercise a clean install from the README and fix every missing step.

## Done when

- A new user can go from clone to first successful workflow using only the README.
- The core workflow works without paid infrastructure unless the brief requires it.
- Tests cover the highest-risk behavior.
- Known limitations are explicit rather than hidden.

# Copy to .env and document every variable when it is introduced.
# Never put real credentials in this file.

APP_ENV=development
# Add only values required by the selected implementation.

# OutFriend product brief

## Problem

This one is closer to buildable than most outreach tools, because OutFriend sends through your own Gmail rather than its own infrastructure. That removes the moat that usually saves this category: no warmup pools, no IP reputation, no deliverability engineering you cannot replicate. What is left is a Gmail OAuth integration, a voice sample you pass to a model, a scheduler with send windows and daily caps, and the one piece that is genuinely fiddly, watching threads so a sequence stops the instant someone replies. That is a weekend if you have written against the Gmail API before, and a long weekend if you have not.

## Product outcome

Pass a sample of your sent mail to a model as voice reference, draft one email per CSV row, queue them through the Gmail API on a throttle, and halt the follow-ups on any reply.

## Target user

A serious builder who needs a maintainable product foundation rather than a one-off demo.

## Required capabilities

- a Google Cloud project with Gmail API access and OAuth consent configured
- an OpenAI or Anthropic API key
- a leads CSV you sourced yourself
- a scheduler that survives your laptop sleeping
- your own read of CAN-SPAM and GDPR before you send anything

## Explicit non-goals for v1

- reply detection that is thread-based rather than naive, so out-of-office replies do not count as interest and a reply from a different address still stops the sequence
- verification and suppression, meaning unverified, bounced and opted-out addresses filtered before anything queues
- a review surface where every draft is readable and editable before it goes, instead of trusting a script with your inbox
- lead generation, which the paid tiers include and your CSV does not
- the Google OAuth verification process, which you will meet the moment you want this on more than your own account

## Success criteria

- The primary workflow is measurable end to end.
- Setup is reproducible in a clean environment.
- Failure, recovery, and support paths are documented.
- Product claims match what the implementation actually guarantees.

# Architecture

## Starting brief

Build me a local cold email sender that drafts in my voice and sends from my own Gmail, to replace OutFriend. Requirements:

- Node 22, TypeScript, SQLite via better-sqlite3, googleapis for Gmail, node-cron for the
  schedule. CLI only. No accounts, no telemetry, OAuth token and API keys in .env.
- `mail auth` runs the Gmail OAuth device flow once and stores the refresh token locally.
  Scopes: gmail.send, gmail.readonly.
- `mail voice` pulls my last 200 sent messages, strips quoted replies and signatures, and
  saves 20 of the shortest complete ones to voice.md as the style reference.
- leads.csv holds email, first name, company and one context column. `mail draft` writes
  one email per row using voice.md plus the context column, saves each as status=draft,
  and refuses to draft for any address already in suppression.txt.
- `mail review` prints drafts one at a time in the terminal and takes approve, edit or
  skip. Nothing sends without an approve. This gate is not optional.
- `mail send` delivers approved drafts through the Gmail API inside a send window from
  config.json, with a daily cap and a random 30 to 180 second gap between sends.
- Every 30 minutes, `mail watch` polls threads for inbound messages. Any reply sets the
  lead to replied and cancels its remaining follow-ups. Treat an auto-reply as a stop
  too, and never as interest.
- Follow-ups are two fixed templates at day 4 and day 10 in the same thread, cancelled by
  any reply or bounce. Parse bounce DSNs and write those addresses to suppression.txt.
- Out of scope: lead sourcing, email verification, inbox warmup, and sending from any
  address that is not my own connected Gmail.
- README: OAuth setup, the send window config, and a plain warning to read CAN-SPAM and
  GDPR before the first campaign.

## Boundaries

Separate the product into replaceable modules for interface, application logic, persistence, external integrations, and operational concerns. Keep domain logic independent from delivery frameworks and vendors.

## Production baseline

- Configuration: validated at startup with safe local defaults where possible.
- Security: least privilege, input validation, secret redaction, rate limits on abuse-prone paths, and no invented security primitives.
- Data: explicit schema and migrations, transactional writes where integrity matters, backup and restore instructions.
- Integrations: adapters around third-party providers, idempotent webhook or job processing, bounded retries, and timeouts.
- Observability: structured logs with request or operation IDs, an error-tracking hook, and health/readiness checks where a server exists.
- Quality: unit tests for domain rules, integration tests at module boundaries, and one end-to-end critical-path test.

## Decision records

For each major dependency, document why it was chosen, its failure mode, and how it can be replaced. Do not introduce infrastructure until a requirement justifies it.

# Agent instructions

- Read `PRODUCT.md` and `ARCHITECTURE.md` before changing code.
- Implement milestone by milestone; keep each change reviewable and leave the application runnable.
- Treat authentication, payments, encryption, imports, webhooks, and destructive actions as high-risk boundaries when present.
- Never invent cryptography or silently weaken a requirement to make a test pass.
- Use provider interfaces for external services and deterministic fakes in tests.
- Add migrations and rollback or recovery notes for persistent data changes.
- Log useful operational context without credentials, tokens, passwords, or personal data.
- Update documentation and run all checks before completing a milestone.

# Delivery milestones

## M0 — Decisions and scaffold

- Confirm the runtime, persistence model, threat boundaries, and deployment target.
- Create a reproducible local environment and continuous checks.

## M1 — Core workflow

- Implement the smallest end-to-end product path with validation and tests.
- Keep integrations behind interfaces.

## M2 — Trust layer

- Add secure failure behavior, recovery paths, audit-relevant events, and data safeguards.
- Test abuse cases and destructive operations.

## M3 — Operability

- Add structured logs, error reporting hooks, health signals, backup/restore documentation, and deployment configuration.

## M4 — Release gate

- Run a clean-install test, critical-path end-to-end test, dependency review, and documented rollback exercise.
- Compare the shipped behavior with `PRODUCT.md` and publish remaining limitations.

# Operations

## Before release

- Validate configuration and secrets at startup.
- Define backup, restore, and rollback procedures and test them.
- Document logs, error tracking, health signals, and alert ownership.
- Set dependency update and vulnerability review expectations.

## Incident checklist

1. Contain the issue without destroying evidence or user data.
2. Record the timeline and affected scope.
3. Rotate exposed secrets and revoke compromised sessions or credentials.
4. Restore from a verified source when needed.
5. Document the root cause, remediation, and regression test.

## Launch constraint

Do not market omitted OutFriend capabilities as implemented. The v1 non-goals in `PRODUCT.md` remain user-visible limitations until they are deliberately delivered.

$ choose a build depth, inspect the files, then open the complete pack in your agent