docs/Codex_Master_Parallel_Agent_Prompt.md

# Codex Master Parallel Agent Prompt

Paste this into a fresh Codex app session.

```text
You are the lead implementation orchestrator for the GrowQR repo at /Users/puter/Workspace/growqr.

Your job is to complete all four new services in parallel using background/sub-agents and keep them running in an implementation-review loop until the work is done. Do not stop after one slice. Do not pause to ask whether you should continue unless there is a true blocker that makes continued implementation unsafe.

## Primary Objective

Fully implement these four services in this repo, using the existing Python FastAPI template and existing repo patterns:

1. /Users/puter/Workspace/growqr/pathways-service
2. /Users/puter/Workspace/growqr/matchmaking-service
3. /Users/puter/Workspace/growqr/marketplace-service
4. /Users/puter/Workspace/growqr/social-branding-service

Each service already has:
- docs/PRD.md
- docs/plan.md

There is also a master orchestration plan here:
- /Users/puter/Workspace/growqr/docs/Four_Service_Overnight_Execution_Plan.md

You must read those docs first and use them as the source of truth for implementation order, scope, dependencies, and review gates.

## Mandatory Working Style

You must behave as a persistent engineering manager plus implementer, not as a one-shot code assistant.

You must:
- spawn background/sub-agents for parallel work
- keep working until all four services reach a genuinely usable implementation state
- use a develop -> test -> review -> fix loop continuously
- update plan checklists inside each service as phases complete
- avoid stopping after partial progress
- make reasonable assumptions and continue
- only ask the user a question if there is a real product contradiction or destructive architecture risk

You must not:
- stop after a single phase and ask “should I continue?”
- stop just because an external API is unavailable
- stop because OAuth, scraping, payments, or third-party integrations are incomplete
- over-focus on one service while ignoring the others
- silently drift outside the plans without documenting the reason

## Completion Standard

Keep going until each service:
- boots locally
- has real models and APIs
- has tests for core flows
- has seed/demo data or fixtures
- has Docker/Compose compatibility
- has README and plan docs updated
- has major PRD features implemented where feasible
- has deferred items explicitly documented only where they are truly blocked by external systems, legal constraints, or unresolved business decisions

“Done” does not mean “I built a scaffold.” It means the service is materially implemented end to end.

## Repository Context To Read First

Read these before implementation:

- /Users/puter/Workspace/growqr/docs/Four_Service_Overnight_Execution_Plan.md
- /Users/puter/Workspace/growqr/docs/Meeting_Notes_3_Week_Delivery_Plan.md
- /Users/puter/Workspace/growqr/docs/PRD_Portfolio_Summary.md
- /Users/puter/Workspace/growqr/pathways-service/docs/PRD.md
- /Users/puter/Workspace/growqr/pathways-service/docs/plan.md
- /Users/puter/Workspace/growqr/matchmaking-service/docs/PRD.md
- /Users/puter/Workspace/growqr/matchmaking-service/docs/plan.md
- /Users/puter/Workspace/growqr/marketplace-service/docs/PRD.md
- /Users/puter/Workspace/growqr/marketplace-service/docs/plan.md
- /Users/puter/Workspace/growqr/social-branding-service/docs/PRD.md
- /Users/puter/Workspace/growqr/social-branding-service/docs/plan.md
- /Users/puter/Workspace/growqr/fastapi-service-template/README.md
- /Users/puter/Workspace/growqr/upskilling_services/services/interview-service/README.md
- /Users/puter/Workspace/growqr/qscore_service/README.md

Inspect the code of existing services before making assumptions.

## Parallelization Plan

Create a top-level execution plan, then spawn:

- one background builder agent for Pathways
- one background builder agent for Matchmaking
- one background builder agent for Marketplace
- one background builder agent for Social Branding
- one background reviewer agent that repeatedly reviews all changed code for bugs, regressions, missing tests, broken assumptions, and plan drift

The reviewer agent’s job is not to implement large features first. Its job is to find defects and missing coverage continuously while the builders are working.

You should continue coordinating these agents until the full program is implemented as far as possible in this session.

## Dependency Order

Respect this order:

1. Pathways must stabilize shared user context, recommendation context, and pathway state contracts first.
2. Matchmaking and Marketplace can build in parallel once Pathways contracts are clear enough.
3. Social Branding should align to Pathways persona/goal/archetype contracts, but should continue independently using placeholders if needed.

Do not block all work waiting for Pathways to be perfect. Use provisional contracts, then reconcile.

## Scope And Delivery Rules

You must attempt to implement the PRDs broadly, but be intelligent about execution order.

When a feature can be implemented with an internal adapter, mock, stub, manual workflow, or admin-assisted fallback, do that now instead of stopping.

Examples:
- scraping unavailable -> create ingestion/import/admin pipeline and scraper adapter interface
- OAuth unavailable -> create manual import adapter and provider interface
- payment gateway unavailable -> create internal transaction state machine and fake payment confirmation flow
- analytics unavailable -> persist locally computed metrics and expose APIs
- external posting unavailable -> build draft generation, approval, and publish confirmation flow

Do not throw away the full PRD vision. Preserve it in:
- models
- adapters
- events
- configuration
- deferred docs

But implement the highest-value runnable version first.

## Service-Specific Expectations

### Pathways
- implement Option A fully first
- build questionnaire, profile ingest, generation, activation, weekly plans, report data, recommendation context
- preserve extension points for Option B, Q-scores, adaptive regeneration, and wider orchestration

### Matchmaking
- implement seeker feed, manual/admin ingestion, ranking, thresholds, feedback loop, action tracking
- preserve extension points for scrapers, enrichment, employer-side flows, and advanced weighting

### Marketplace
- implement provider application, approval, listings, browse/search/filter, recommendations, booking state machine
- fully implement live 1:1, async review, done-for-you first
- preserve extension points for payments, retainer, group sessions, guarantees, demand aggregation, and pre-booking

### Social Branding
- implement LinkedIn-first individual flow
- build import/audit, Brand Score, persona strategy, content calendar, draft generation, approval queue, publish confirmation, dashboard
- preserve extension points for OAuth, multi-platform support, enterprise workflows, and auto-posting

## Review Loop Requirements

After each meaningful implementation chunk:
- run relevant tests
- add tests if missing
- review changed code against PRD and plan
- update checkboxes in docs/plan.md
- continue immediately to the next phase

If a builder agent finishes its assigned phases early, reassign it to help:
- fix reviewer findings
- add tests
- harden Docker/Compose
- improve docs
- complete deferred-but-feasible items

## Stop Conditions

Do not stop unless one of these is true:
- there is a direct contradiction between required documents that materially changes implementation
- continuing would require a destructive schema decision that could break all four services
- a missing secret, API, or external integration cannot be bypassed with a fallback and blocks a critical required path

If you hit a stop condition:
- document the blocker clearly
- propose the exact smallest decision needed
- continue all unaffected work in parallel

## Deliverables Before You Finally Stop

Before ending the session, make sure there is:
- implemented code in all four service folders
- updated docs/plan.md checklists
- updated READMEs where needed
- tests passing where feasible
- clear notes on any real blockers or remaining external integration work

Start now by:
1. reading the master plan and all four service plans
2. building a concise orchestration plan
3. spawning the sub-agents
4. beginning implementation immediately
5. continuing until the whole program is substantially complete
```

## Shorter Version

Use this if you want a tighter prompt:

```text
Act as the lead orchestrator for /Users/puter/Workspace/growqr and complete these four services in parallel using background/sub-agents:

- /Users/puter/Workspace/growqr/pathways-service
- /Users/puter/Workspace/growqr/matchmaking-service
- /Users/puter/Workspace/growqr/marketplace-service
- /Users/puter/Workspace/growqr/social-branding-service

Read first:
- /Users/puter/Workspace/growqr/docs/Four_Service_Overnight_Execution_Plan.md
- /Users/puter/Workspace/growqr/docs/Meeting_Notes_3_Week_Delivery_Plan.md
- /Users/puter/Workspace/growqr/docs/PRD_Portfolio_Summary.md
- each service’s docs/PRD.md
- each service’s docs/plan.md

Spawn 4 builder agents + 1 reviewer agent. Keep them running in a develop -> test -> review -> fix loop until all four services are materially implemented end to end. Do not stop after a slice and do not ask whether to continue unless there is a true blocker.

Use fallbacks instead of stopping:
- admin/manual ingestion instead of scrapers
- internal/fake transaction flow instead of real payments
- manual import instead of blocked OAuth
- adapter interfaces for future integrations

Pathways first for shared contracts, then Matchmaking and Marketplace in parallel, then Social Branding aligned to Pathways context. Update each docs/plan.md checklist as phases complete. Before stopping, ensure each service has real models, APIs, tests, Docker compatibility, and explicit documentation of any truly blocked remainder.
```