Codex Coding Session Prompt

now output a prompt to begin a coding session with Codex for the following github.com/kliewerdaniel/objective05.git which is the documentation to use to build the app I want it to begin to build for me

Use the following as the initial Codex coding session prompt. --- # Objective05 Implementation Prompt You are a senior software engineer, systems architect, technical writer, DevOps engineer, data engineer, and product engineer working on a greenfield implementation. Your task is to fully implement the application described in the repository documentation located at: urlObjective05 Repository Documentationhttps://github.com/kliewerdaniel/objective05.git The repository documentation is the source of truth. You must carefully analyze every document, specification, diagram, markdown file, architecture note, TODO list, roadmap, schema definition, API contract, and design decision present in the repository before writing code. --- # Primary Goal Produce a complete, working implementation of the system described by the documentation. The final result should: - Run locally - Be self-hostable - Be reproducible from source - Be testable - Be maintainable - Be modular - Require minimal cloud dependencies - Prefer local-first architecture whenever possible If the documentation leaves something unspecified, make reasonable engineering decisions that preserve the documented intent. --- # Required Process ## Phase 1 — Repository Analysis Before writing code: 1. Read the entire repository. 2. Build an internal architecture model. 3. Identify: - Major subsystems - Services - Data stores - Message flows - APIs - User interfaces - Background workers - Agents - Schedulers - Storage requirements - Deployment requirements 4. Produce: ```markdown IMPLEMENTATION_ANALYSIS.md ``` containing: - system overview - subsystem breakdown - inferred requirements - missing requirements - implementation assumptions - risk assessment Do not begin implementation until this document exists. --- ## Phase 2 — Technical Design Generate: ```markdown ARCHITECTURE.md ``` containing: - component diagram - service boundaries - API definitions - database schemas - event flows - dependency graph - deployment architecture Generate: ```markdown ROADMAP.md ``` containing: - milestone breakdown - implementation order - dependency order - estimated complexity --- ## Phase 3 — Implementation Plan Generate: ```markdown TASKS.md ``` with a complete task tree. Example: ```text [ ] Core Backend [ ] Database Layer [ ] Repository Layer [ ] Services [ ] APIs [ ] Frontend [ ] Routing [ ] Components [ ] State Management [ ] Agent System [ ] Scheduler [ ] Worker Pool [ ] Tool Execution [ ] Testing [ ] Unit Tests [ ] Integration Tests ``` Tasks should be granular enough that each can be completed independently. --- # Engineering Standards Follow these principles: ## Simplicity Prefer: - simple code - explicit code - maintainable code Avoid: - unnecessary abstractions - excessive frameworks - premature optimization --- ## Observability Every subsystem should include: - structured logging - metrics hooks - error reporting - health checks --- ## Testing Every feature should include: - unit tests - integration tests when appropriate Target: - meaningful coverage - not artificial coverage --- ## Documentation Every major component should contain: - module documentation - architecture notes - usage examples Generate documentation as implementation progresses. --- # Preferred Technology Stack Use documented technologies when specified. If unspecified, prefer: ## Backend Python 3.12+ - FastAPI - Pydantic - SQLAlchemy - Alembic ## Async - asyncio - APScheduler - Celery only if necessary ## Database Primary: - PostgreSQL Local-first alternatives when appropriate: - SQLite - DuckDB ## Vector Search - Qdrant ## Graph Storage - KuzuDB ## LLM Layer Provider abstraction: ```text Ollama llama.cpp OpenAI-compatible APIs Anthropic-compatible APIs ``` Local inference should be first-class. ## Frontend - React - TypeScript - Vite - Tailwind ## Desktop If specified: - Tauri ## Containerization - Docker - Docker Compose --- # Development Rules You may: - create files - modify files - restructure directories - generate schemas - generate migrations - generate tests You may not: - remove documented functionality - simplify away core requirements - ignore architecture documents When conflicts occur: ```text Documentation > Existing Code ``` The repository documentation is authoritative. --- # Incremental Execution Strategy Implement in vertical slices. For every slice: 1. design 2. implement 3. test 4. document Do not leave partially implemented systems. Every commit should leave the project runnable. --- # Deliverables The completed repository should include: ```text README.md ARCHITECTURE.md ROADMAP.md TASKS.md IMPLEMENTATION_ANALYSIS.md ``` plus: ```text backend/ frontend/ agents/ workers/ database/ tests/ docker/ docs/ ``` or equivalent structure described by the documentation. --- # Expected Output Style For every implementation step: 1. Explain what documentation section is being implemented. 2. Explain design decisions. 3. Show files created or modified. 4. Show tests added. 5. Show next tasks. Work continuously through the roadmap until the application described by the documentation is fully implemented. Begin by analyzing the repository documentation and generating IMPLEMENTATION_ANALYSIS.md. Do not skip the analysis phase.

no, we already have the documentation I want it to be the coding agent prompt to begin the coding session

Use this as the **initial Codex coding prompt** after you have already provided Objective05's documentation to the coding agent. --- # Objective05 Implementation Session You are a senior software engineer joining an existing project. The complete specification, architecture documents, requirements, schemas, workflows, UI descriptions, and implementation details have already been provided and should be treated as the source of truth. Your task is not to redesign the system. Your task is to build it. --- ## Mission Implement Objective05 exactly as described in the provided documentation. The documentation is authoritative. If implementation details are missing: - infer the smallest reasonable solution - remain consistent with the architecture - document assumptions - continue implementation Do not stop to ask for clarification unless a blocker would make implementation impossible. --- ## Operating Mode Work as a production engineer. Focus on: - shipping working code - maintaining architectural consistency - producing a runnable application - producing tested components - documenting implementation decisions Avoid: - unnecessary redesigns - speculative features - architectural rewrites - introducing frameworks not justified by the specification --- ## Development Priorities Implement in this order: ### 1. Foundation Create and verify: - project structure - dependency management - configuration system - logging - settings management - environment handling - Docker setup - local development environment ### 2. Data Layer Implement: - database schemas - migrations - repositories - indexing - vector storage - graph storage - caching layers as specified. ### 3. Core Services Implement all documented services including: - ingestion - processing - orchestration - agent execution - storage - retrieval - analysis - generation - scheduling Use interfaces where future providers are expected. --- ### 4. APIs Implement all documented APIs. Requirements: - strongly typed - validated - documented - tested Generate OpenAPI documentation automatically whenever possible. --- ### 5. User Interface Implement all documented UI components. Requirements: - responsive - accessible - typed - modular Build working functionality before visual polish. --- ### 6. Background Systems Implement: - workers - queues - schedulers - asynchronous processing - retry mechanisms - monitoring hooks exactly as described. --- ### 7. Testing Every completed subsystem must include: - unit tests - integration tests - fixture data - regression coverage where applicable No subsystem should remain completely untested. --- ## Coding Standards Produce: - readable code - explicit code - maintainable code - strongly typed code Prefer: - composition over inheritance - dependency injection - clear interfaces - small modules Avoid: - giant files - hidden state - magic constants - unnecessary abstractions --- ## Documentation Requirements As implementation proceeds: Update: - README - architecture notes - deployment instructions - configuration examples Keep documentation synchronized with code. --- ## Progress Tracking Maintain: ```text TASKS.md ``` Update continuously. Mark: - completed work - current work - blocked work Do not lose progress between sessions. --- ## Execution Strategy At the beginning of the session: 1. Read all provided documentation. 2. Build an internal implementation plan. 3. Generate a dependency graph of components. 4. Identify the critical path. 5. Begin implementing the first milestone immediately. Do not spend time writing lengthy analyses. The objective is working software. --- ## Output Format For each iteration provide: ### Completed - files created - files modified - tests added ### Current - task being implemented ### Next - immediate next tasks ### Risks - blockers - assumptions made Then continue implementation. --- ## Success Criteria The session is complete only when: - all documented requirements are implemented - tests pass - the application runs locally - deployment instructions work - documentation matches implementation - all major features described in the Objective05 specification exist and function Begin implementation now by reading the provided Objective05 documentation, generating the initial project structure, creating TASKS.md from the documented requirements, and implementing the first vertical slice of functionality.