Step 1: Getting Context (without RAG)

1) Required Repositories (Local Context Collection Without RAG)

This implementation does not require enterprise-ai-infra, Qdrant, MCP, or any vector ingestion services.

The only required repository is:

bitovi/ai-enablement-prompts

All target application repositories (for example, bitovi-training microservices) will be discovered and cloned dynamically during execution of the Systems Map prompt.

Minimum clone set:

ai-enablement-prompts (prompt definitions)
Target system repositories (auto-cloned into workdir/repos during discovery)

No additional infrastructure repositories are required.

2) Clone + Setup solutions-architect

From a parent directory:

git clone https://github.com/bitovi/ai-enablement-prompts.git
cd ai-enablement-prompts
git checkout solutions-architect

Create required local working directories:

mkdir -p output
mkdir -p workdir/repos

No .env configuration is required.

No external services need to be started.

3) Validate Local Environment

Before collecting context, confirm:

Git is installed and available
You have read access to the target repositories
The anchor artifact (for example, docker-compose.yml) exists and is accessible

All analysis will be performed locally inside:

workdir/repos

4) Collect Context from Source Code

All context gathering is performed through the map_system prompt.

Context collection begins from a defined anchor artifact, such as:

bitovi-training/service-infra/docker-compose.yml

Prompts are available inside:

ai-enablement-prompts/solutions-architect-non-rag/map_system.prompt.md
ai-enablement-prompts/solutions-architect-non-rag/plan_solution.prompt.md

The agent will:

Read docker-compose.yml to identify:
- Services
- Ports
- Environment variables
- Build contexts
Derive repository names from build contexts
Clone related repositories into:
workdir/repos/<repo-name>
Perform local file search to extract:
- Route registrations
- Controller definitions
- Middleware and authentication usage
- HTTP client calls between services
- DTOs and payload structures
Trace service-to-service integrations
Validate request and response contracts directly from code

All findings are evidence-based and sourced from actual files.

No indexing or ingestion step is required.

5) Confirm Context Coverage

After context collection, confirm that:

All services defined in docker-compose are included
All outbound service calls are documented
The authentication model is identified
Environment variables driving service communication are captured
Payload structures are verified from DTOs or models

This completes context gathering for Systems Map and Solution Plan generation.

The collected context will be used in the next step to generate:

solutions-architect-non-rag/output/SYSTEMS_MAP.md
solutions-architect-non-rag/output/SOLUTION_PLAN.md