# Artifex — V1 Bootstrap Specification > **Artifex V1** is the smallest trustworthy self-hosting version of Artifex: enough control plane, Project Brain, Archaeologist, agent runtime, verification, and Progeny capability to help build Artifex V2. ## 1. Purpose V1 is not intended to implement the entire Artifex. V1 exists to bootstrap the platform. Its primary success criterion is: > **V1 can inspect its own repository, understand its own architecture and intended direction, collaborate with GPT-5.6 Sol on a V2 plan, autonomously implement a meaningful set of missing V2 capabilities in isolated Git worktrees, verify those changes, and produce a candidate V2 branch for promotion.** The full platform architecture remains defined in the master specification. This document defines only the minimum system required to reach self-hosted development. --- # 2. V1 Product Thesis The platform is a persistent autonomous engineering runtime. The core abstractions are: ```text PROJECT BRAIN = intent ARCHAEOLOGIST = evidence PLANNER = decomposition RUNTIME = execution WORKERS = action JUDGES = truth PROGENY = agent improvement ``` V1 should prove that these components can work together on real repositories for long-running engineering tasks. --- # 3. V1 Bootstrap Goal V1 is complete when it can execute this loop: ```text V1 Repository ↓ Project Archaeologist ↓ Observed Architecture ↓ Inferred Intent ↓ Sol Project Brain ↓ V2 Plan ↓ Dynamic Task DAG ↓ Autonomous Workers ↓ Git Worktrees ↓ Tests / Review / Verification ↓ Candidate V2 Branch ``` The system does not need to automatically promote or deploy V2. Human approval of the final candidate is acceptable and preferred for V1. --- # 4. V1 Non-Goals Do not block V1 on: ```text Full Game Studio Full Model Studio Full Steward implementation Distributed Temporal execution Full deployment orchestration Advanced cross-project learning Large multi-model routing matrix Advanced visual asset generation Full UI Arena Complex training pipelines Full Progeny workflow evolution External enterprise integrations Multi-user teams Production-grade SaaS tenancy ``` Those are V2+ capabilities. V1 only needs enough abstractions that these can be added later without architectural rewrites. --- # 5. V1 Studios V1 supports one primary Studio: > **Web App / Software Project Studio** This Studio must work on: ```text new Python/Django-style repositories existing Python repositories the Builder repository itself ``` Game Studio and Model Studio interfaces may exist as placeholders, but they are not required for bootstrap success. --- # 6. V1 Entry Modes V1 supports two project entry modes: ```text 1. New Project 2. Archaeologist ``` ## New Project ```text Idea ↓ Sol Planning Chat ↓ Structured Project Plan ↓ Send to Builder ↓ Build ``` ## Archaeologist ```text Existing Repository ↓ Deep Research ↓ Observed Specification ↓ Inferred Specification ↓ Gap Analysis ↓ Sol Archaeologist Chat ↓ Resurrection / Extension Plan ↓ Build ``` For self-hosting, V1 uses Archaeologist against its own repository. --- # 7. Project Lifecycle V1 lifecycle states: ```text PLANNING READY ARCHAEOLOGY BUILDING PAUSING PAUSED BLOCKED VERIFYING FINISHED FAILED ``` Optional placeholders may exist for: ```text RESURRECTING EXTENDING EVOLVING STEWARD ``` but full implementations are not required for bootstrap. --- # 8. Sol Project Brain GPT-5.6 Sol is the high-level Project Brain. It is responsible for: ```text planning conversations intent clarification architecture reasoning scope decisions major tradeoffs acceptance criteria interpreting Archaeologist findings resolving ambiguous project questions reviewing high-level progress ``` Sol should not be used for every low-level coding task. --- # 9. Project Brain State Persist project-level information externally. Minimum state: ```text project goal planning conversation references Project Plan versions architecture summary decisions current milestones current task graph Archaeologist findings Observed Specification Inferred Specification Target Specification blocked decisions verification summaries ``` The system should retrieve relevant context for Sol when needed. Do not depend on one ever-growing chat transcript. --- # 10. Project Planning Chat New Project opens a Sol planning session. The conversation should generate a structured Project Plan containing: ```text goal scope technical stack architecture features constraints acceptance criteria permissions resource budget open decisions ``` UI concept: ```text PROJECT PLAN Vision ✓ Architecture ✓ Technical Stack ✓ Major Features ✓ Acceptance Criteria ✓ Constraints ✓ Open Decisions 1 Readiness: 92% [ Send to Builder ] ``` --- # 11. Project Plan Contract Minimal schema: ```yaml project_plan: version: 1 goal: ... scope: ... stack: ... architecture: ... milestones: ... constraints: ... acceptance_criteria: ... permissions: ... budget: ... open_decisions: ... ``` Execution always references a specific Project Plan version. --- # 12. Project Archaeologist Archaeologist is mandatory for V1. It should inspect: ```text README files docs source tree package metadata Docker files environment files tests routes models migrations templates frontend assets TODO / FIXME Git status Git history branches commit messages CI configuration dead / unused code where detectable ``` Its objective is: > Determine what this repository is, what it currently does, what it appears intended to become, and what remains incomplete. --- # 13. Archaeologist Output Minimum output: ```text PROJECT UNDERSTANDING Likely Product: ... Confidence: ... Implemented: ✓ ... Partially Implemented: △ ... Broken: ! ... Likely Intended: ○ ... Uncertain / Possibly Abandoned: ? ... Recommended Next Steps: 1. ... 2. ... 3. ... ``` Machine-readable output should also include evidence and confidence. --- # 14. Archaeologist Confidence Every inferred requirement should contain: ```text requirement confidence evidence status ``` Example: ```json { "requirement": "Project supports reusable agent definitions", "confidence": 0.94, "evidence": [ "agent registry model exists", "agent routes exist", "UI references agent definitions", "tests cover agent versioning" ], "status": "partial" } ``` Do not allow Archaeologist to treat weak historical evidence as authoritative scope. --- # 15. Archaeologist → Sol Handoff After research: ```text Archaeologist ↓ Evidence / Findings ↓ Sol Archaeologist Chat ``` Sol and the user refine: ```text what was intended what should be ignored what should be completed what should change ``` Then produce a Target Specification. For self-bootstrap, this becomes the V2 plan. --- # 16. Deterministic Control Plane V1 should explicitly separate: ```text DETERMINISTIC CONTROL PLANE AGENT DECISION LAYER VERIFICATION LAYER ``` Deterministic control plane owns: ```text project state task state permissions budgets Git operations worktrees tool execution event history checkpoints artifacts tests pause/resume ``` LLMs should not own canonical state. --- # 17. Discover / Plan / Execute / Verify Every significant workflow should map to: ```text DISCOVER PLAN EXECUTE VERIFY ``` Default permissions: ```text DISCOVER read-only PLAN read + create plans/tasks EXECUTE capability-scoped mutation VERIFY read + tests + review + pass/reject ``` This separation should be enforced structurally where practical. --- # 18. Project Hierarchy V1 graph hierarchy: ```text PROJECT ↓ MILESTONE ↓ FEATURE ↓ TASK ↓ ACTION ``` Milestones are stable anchors. Tasks remain dynamic. --- # 19. Milestones Every Project Plan should create initial milestones. Example: ```text M1 Control Plane M2 Project Archaeologist M3 Agent Registry M4 Autonomous Build Loop M5 Self-Bootstrap ``` A milestone has: ```text goal dependencies features verification contract status ``` --- # 20. Dynamic Task DAG Tasks live in PostgreSQL. Required fields: ```text task_id project_id milestone_id feature_id type status priority goal acceptance criteria dependencies assigned agent worktree retry count created_at updated_at ``` Statuses: ```text QUEUED READY RUNNING WAITING_TOOL REVIEW BLOCKED FAILED COMPLETE ``` --- # 21. Runtime Graph Use LangGraph for the relatively stable execution graph. Example: ```text PLAN / REFRESH TASKS ↓ SELECT READY TASK ↓ PREPARE WORKTREE ↓ EXECUTE ↓ TEST ↓ REVIEW ↓ PASS? ┌────────┴────────┐ ▼ ▼ NO YES │ │ DEBUG COMMIT │ │ └──────↺ ▼ UPDATE DAG ↓ MORE WORK? ``` The dynamic project DAG remains application state, not a giant compiled LangGraph. --- # 22. GraphRuntime Abstraction Wrap LangGraph. ```python class GraphRuntime: async def start(self, project_id): ... async def pause(self, run_id): ... async def resume(self, run_id): ... async def cancel(self, run_id): ... async def signal(self, run_id, event): ... ``` Initial backend: ```python class LangGraphRuntime(GraphRuntime): ... ``` --- # 23. Event Bus V1 needs a persisted Event Bus. Core events: ```text PROJECT_CREATED PLAN_APPROVED MILESTONE_CREATED TASK_CREATED TASK_READY TASK_STARTED TASK_COMPLETED TASK_FAILED TEST_FAILED REVIEW_FAILED COMMIT_CREATED MILESTONE_VERIFIED PROJECT_BLOCKED PROJECT_PAUSED PROJECT_RESUMED PROJECT_FINISHED AGENT_CREATED AGENT_PROMOTED ``` Consumers: ```text UI activity stream Scheduler Project Brain Metrics Progeny Notifications ``` --- # 24. Project Knowledge Graph Implement a minimal Project Knowledge Graph. Minimum node classes: ```text File Symbol Test Task Milestone Requirement Decision Commit Agent Artifact ``` Minimum edges: ```text contains imports calls tests implements depends_on changed_by validated_by generated_by ``` V1 does not require a dedicated graph database. PostgreSQL tables or adjacency structures are acceptable. --- # 25. Context Builder Workers should not receive entire repositories. Context Builder composes: ```text task contract relevant source files adjacent tests architecture summary relevant decisions recent Git diff symbol neighbors ``` Context selection should be logged so Progeny can improve it later. --- # 26. Agent Registry Agents are first-class versioned objects. V1 must include a global Agents section. Minimum initial agents: ```text Project Archaeologist Planner Coder Reviewer Project Judge ``` Optional: ```text UI Designer Django Architect Security Reviewer ``` --- # 27. Agent Definition Each agent version stores: ```text name role version model system contract capabilities tools permissions context policy workflow retry policy evaluator benchmark status promotion status ``` --- # 28. Create New Agent V1 should support: > **+ New Agent** Workflow: ```text Sol Agent Design Chat ↓ Structured Agent Plan ↓ Candidate Agent ↓ Benchmark ↓ Independent Evaluation ↓ Champion v1 ``` Example: ```text User: "I need an agent that is very good at Django migrations." Sol: defines capabilities tools permissions workflow benchmarks success criteria ``` --- # 29. Agent Actions Agent Control Room should support: ```text Create Open Extend Evolve Fork ``` For V1, `Extend` and `Evolve` can be minimal but should preserve the correct data model. --- # 30. Agent Control Room Minimum tabs: ```text Overview Definition Runs Versions Benchmarks Failures Chat ``` Show: ```text Champion version model capabilities tools task success rate recent runs benchmark score ``` --- # 31. Progeny V1 V1 Progeny is intentionally small. It only needs to prove: > A registered agent can be changed, replayed against a benchmark set, compared with the current Champion, and promoted or rejected. Targets: ```text agent system contract context policy workflow model choice ``` V1 does not need broad autonomous policy evolution. --- # 32. Progeny Champion / Challenger ```text Agent Champion ↓ Create Challenger ↓ Replay Benchmark Tasks ↓ Compare ↓ Promote / Reject ``` Minimum metrics: ```text completion rate test pass rate review acceptance tokens runtime ``` --- # 33. Dynamic Agent Teams V1 should not use a permanent swarm. Scheduler selects agents from the registry according to task type. Example: ```text Architecture task → Planner / Architect Implementation → Coder Verification → Reviewer Final gate → Judge ``` Multiple workers may run concurrently if independent tasks are READY. --- # 34. Worker Communication Agents should rarely chat directly. Preferred coordination channels: ```text task contracts structured findings Git artifacts events Project Knowledge Graph Project Brain decisions ``` --- # 35. Git Worktrees Every mutable engineering task should use an isolated Git worktree. Flow: ```text Task ↓ Create worktree ↓ Execute ↓ Tests ↓ Review ↓ Commit ↓ Integrate ``` Store task ↔ worktree ↔ branch ↔ commit lineage. --- # 36. Tool Runtime Minimum tools: ```text filesystem shell Git pytest Ruff mypy where configured Docker browser / Playwright if available ``` Tool execution is outside the model context. --- # 37. Capability Permissions Agents receive capabilities, not raw unrestricted shell access. Examples: ```text read_repository write_worktree run_tests create_branch commit_changes browser_test ``` High-risk capabilities remain unavailable in V1: ```text deploy_production delete_production_data arbitrary secret access unrestricted host filesystem ``` --- # 38. Global Secret Registry V1 should include a minimal Global Secret Registry. Examples: ```text GitHub token model API key Hugging Face token AWS / Bedrock credentials ``` Rules: ```text register once grant per project/tool never put raw secrets into prompts inject at tool execution time audit usage ``` UI: ```text Settings └── Secrets ``` --- # 39. Global Resource Registry V1 should model reusable resources: ```text Models Secrets Compute Git Artifact Storage ``` Example: ```text Models GPT-5.6 Sol Qwen 27B Compute DGX Spark Git GitHub ``` Projects reference resources rather than duplicating configuration. --- # 40. Model Router Minimum routing: ```text Sol → planning / archaeology interpretation / agent design / major escalation Qwen 27B → coding / reviewing / routine engineering work ``` The interface should permit more models later. --- # 41. Inference Queue V1 needs a simple model request queue. Track: ```text request agent project priority model token budget status ``` Advanced GPU scheduling is V2. --- # 42. Multi-Level Verification V1 verification levels: ```text TASK VERIFY MILESTONE VERIFY PROJECT VERIFY ``` ## Task Verify Checks task acceptance criteria. ## Milestone Verify Runs the milestone's integrated test contract. ## Project Verify Checks the final Target Specification. Only Project Verify may set: ```text FINISHED ``` --- # 43. Reviewer vs Judge Reviewer: ```text reviews implementation quality finds issues requests changes ``` Judge: ```text decides whether an acceptance contract is satisfied PASS / FAIL ``` The implementing agent may never self-certify completion. --- # 44. Project Dashboard Home screen: ```text ARTIFEX [ + New Project ] PROJECTS Builder V1 WEB APP / PLATFORM BUILDING 67% 3 agents running 2 ready [ Open ] [ Pause ] Example Django App WEB APP FINISHED [ Open ] ``` --- # 45. Project Control Room Minimum views: ```text Overview Chat Plan Graph Agents Activity Tests Git Decisions ``` --- # 46. Overview Show: ```text project type status progress current milestone active agents ready tasks blocked tasks failed tasks recent commits verification status ``` --- # 47. Graph View Render the hierarchical plan/task graph. Example: ```text M4 Autonomous Build Loop │ ├── Task Scheduler ├── Worktree Manager ├── Coder Worker ├── Reviewer └── Integration ``` Clicking a node shows: ```text contract dependencies agent tool calls changed files tests review commit runtime tokens ``` --- # 48. Activity Stream Persist and display Event Bus events. Example: ```text 12:01 TASK-142 started by Coder-v3 12:04 pytest failed 12:08 Coder-v3 committed fix 12:09 Reviewer-v2 started 12:12 TASK-142 completed ``` --- # 49. Pause / Resume Pause: ```text stop scheduling new tasks allow safe atomic operations to finish persist runtime state persist graph checkpoint mark PAUSED ``` Resume: ```text reload state validate worktrees reconcile incomplete actions return valid tasks to READY continue ``` --- # 50. Decision Log Record significant Project Brain/user decisions. Fields: ```text decision_id type decision reason evidence project plan version timestamp actor ``` Workers retrieve relevant decisions during context construction. --- # 51. Artifact Registry V1 artifact types: ```text plans reports screenshots test reports generated files build outputs benchmark outputs ``` Git remains canonical for source. Artifact Registry handles non-source outputs. --- # 52. Budgets V1 supports simple budgets: ```text maximum model tokens maximum runtime maximum retries maximum concurrent tasks ``` Hard limits should pause/escalate rather than silently exceed. --- # 53. Project Health Minimal project health indicators: ```text build tests blocked tasks recent failures verification ``` A single overall score is optional. --- # 54. Steward Placeholder Full Steward is not required for bootstrap. V1 should still define the interface and Event Bus integration. Initial Steward may only handle: ```text scheduled project health review dependency warning events failed CI/build events secret expiry events ``` Steward produces findings. It does not need automatic Repair in V1. --- # 55. V1 Persistence Use PostgreSQL. Minimum domains: ```text projects plans milestones features tasks dependencies agents agent_versions agent_runs events decisions artifacts worktrees commits tests reviews verifications secrets_metadata resource_registry ``` --- # 56. V1 Repository Structure Suggested: ```text autonomous-builder/ │ ├── control_plane/ │ ├── projects/ │ ├── plans/ │ ├── agents/ │ ├── resources/ │ ├── permissions/ │ └── events/ │ ├── project_brain/ │ ├── sol.py │ ├── context.py │ └── decisions.py │ ├── archaeology/ │ ├── scanner.py │ ├── git_history.py │ ├── inference.py │ └── report.py │ ├── graph/ │ ├── runtime.py │ ├── langgraph_runtime.py │ ├── scheduler.py │ └── state.py │ ├── knowledge/ │ ├── graph.py │ ├── symbols.py │ ├── retrieval.py │ └── context_builder.py │ ├── agents/ │ ├── registry.py │ ├── base.py │ ├── planner.py │ ├── coder.py │ ├── reviewer.py │ ├── judge.py │ └── progeny.py │ ├── models/ │ ├── router.py │ ├── sol.py │ ├── qwen.py │ └── queue.py │ ├── tools/ │ ├── filesystem.py │ ├── shell.py │ ├── git.py │ ├── tests.py │ └── docker.py │ ├── workspace/ │ ├── worktrees.py │ └── sandbox.py │ ├── verification/ │ ├── task.py │ ├── milestone.py │ └── project.py │ ├── artifacts/ │ └── registry.py │ ├── secrets/ │ ├── registry.py │ └── broker.py │ ├── ui/ │ └── ... │ └── tests/ ``` --- # 57. V1 Build Order Recommended order: ```text 1. Django project / control-plane skeleton 2. PostgreSQL schema 3. Project + Plan models 4. Event Bus 5. Agent Registry 6. Global Resource Registry 7. Secret Registry 8. Sol Project Brain integration 9. Model Router 10. Qwen worker integration 11. Tool Runtime 12. Git Worktree Manager 13. Dynamic Project DAG 14. LangGraph GraphRuntime 15. Planner agent 16. Coder agent 17. Reviewer agent 18. Judge agent 19. Task verification 20. Milestone verification 21. Project verification 22. Project Archaeologist 23. Archaeologist → Sol handoff 24. Project Knowledge Graph 25. Context Builder 26. Project Dashboard 27. Project Control Room 28. Pause / Resume 29. Create New Agent 30. Minimal Progeny champion/challenger loop 31. Self-bootstrap milestone ``` --- # 58. Bootstrap Milestones ## M1 — Control Plane Complete when: ```text projects persist plans persist events persist tasks persist agents persist dashboard renders ``` ## M2 — Autonomous Task Loop Complete when: ```text task selected worktree created Coder modifies code tests run Reviewer reviews Judge passes/rejects commit recorded ``` ## M3 — Planning Complete when: ```text Sol planning chat creates structured Project Plan and task DAG ``` ## M4 — Archaeologist Complete when: ```text existing repo inspected Git history analyzed Observed/Inferred specs produced Sol receives archaeology context ``` ## M5 — Agent Registry / Progeny Complete when: ```text new agent can be created agent versions exist benchmark replay exists challenger can be promoted/rejected ``` ## M6 — Self-Bootstrap Complete when V1 can improve itself. --- # 59. Self-Bootstrap Test The definitive V1 test: ## Step 1 Point V1 Archaeologist at the V1 repository. ## Step 2 Provide the master platform specification as architectural intent. ## Step 3 Archaeologist produces: ```text Observed V1 capabilities Missing master-spec capabilities Architecture gaps Likely V2 priorities ``` ## Step 4 Open Sol Project Brain chat. User and Sol define: ```text V2 scope milestones acceptance criteria budget ``` ## Step 5 Select: > **Send to Builder** ## Step 6 V1 autonomously: ```text creates V2 task DAG creates isolated worktrees implements tasks runs tests reviews changes verifies milestones commits accepted work ``` ## Step 7 V1 produces: ```text candidate/v2 ``` with: ```text summary commits tests verification results known issues unfinished tasks ``` ## Step 8 Human reviews and promotes or rejects. --- # 60. Minimum V2 Work V1 Must Build The self-bootstrap test should require multiple non-trivial features. Suggested candidate set: ```text Event-driven Steward improvement Agent Control Room enhancements Extend Agent workflow Evolve Agent workflow Project-specific agent specialization Improved Knowledge Graph traversal Policy versioning Workflow versioning ``` V1 does not need to build all of them. It should successfully build enough to prove generality. --- # 61. Bootstrap Success Metrics Suggested minimum metrics: ```text ≥ 70% autonomous completion on selected V2 tasks 100% accepted commits pass required tests 0 direct writes to protected main branch 0 raw secret leakage into prompts/logs all accepted tasks have traceable worktree + commit lineage all milestones have verification records pause/resume successfully demonstrated at least one agent Challenger benchmarked by Progeny ``` These targets may be adjusted after the first real runs. --- # 62. V1 Dogfooding Rule After the autonomous task loop is stable: > **Use V1 to implement as much of V2 as practical.** Manual engineering remains acceptable for: ```text critical runtime failures unsafe permission bugs broken persistence benchmark harness defects foundational architecture corrections ``` But ordinary feature work should increasingly be routed through the Builder itself. --- # 63. V1 Security Rules Mandatory: ```text repository contents are untrusted input raw secrets never enter LLM prompts workers write only to isolated worktrees main branch is protected production deployment unavailable tool permissions are explicit Judge is independent from implementer event/audit history is persisted ``` --- # 64. V1 UX Principle The product should not feel like a collection of agent framework controls. Primary user interactions: ```text Talk to Sol about intent. Inspect what the system understands. Watch autonomous execution. Intervene when needed. Review verified results. ``` Do not require users to manually draw graphs or edit orchestration YAML for normal operation. --- # 65. V1 Home Navigation ```text Projects Agents Resources Activity Settings ``` ## Projects Create and monitor projects. ## Agents Create, inspect and improve worker agents. ## Resources Models, compute and reusable integrations. ## Activity Cross-project Event Bus activity. ## Settings Secrets, platform preferences and runtime configuration. --- # 66. V1 Project Actions During build: ```text Open Pause Resume Stop ``` After verified completion: ```text Open ``` `Extend`, `Evolve`, and full `Steward` unlock in V2. The underlying schema may anticipate them. --- # 67. V1 Agent Actions Required: ```text New Agent Open Agent Fork Agent Create Challenger Benchmark Challenger Promote / Reject ``` Optional V1 UX aliases: ```text Extend Agent Evolve Agent ``` These may initially map to Sol-guided Challenger creation. --- # 68. Definition of V1 Done V1 is DONE when: ```text ✓ Sol can turn an idea into a structured Project Plan ✓ Archaeologist can understand an existing repository ✓ Sol can reason over Archaeologist findings ✓ Project hierarchy supports milestones/features/tasks/actions ✓ Event Bus records execution ✓ LangGraph runtime can execute the autonomous task loop ✓ Qwen workers can implement repository changes ✓ work is isolated in Git worktrees ✓ Reviewer and Judge are independent ✓ Task/Milestone/Project verification exists ✓ Project Dashboard and Control Room exist ✓ projects can pause and resume ✓ Agent Registry exists ✓ a New Agent can be created through Sol ✓ minimal Progeny can benchmark a Challenger ✓ Secret Registry exists ✓ V1 can use itself to build meaningful V2 functionality ``` If the final line is not true, the bootstrap objective has not yet been met. --- # 69. What Comes Immediately After V1 Once self-bootstrap succeeds, prioritize V2 work through V1 itself. Likely V2 sequence: ```text 1. Extend Project 2. Evolution chat + campaigns 3. Full Progeny policy/workflow evolution 4. Event-driven Steward 5. Agent Control Room expansion 6. Project-specific agent specialization 7. UI Arena / visual agent evaluation 8. Game Studio 9. Model Studio 10. Training Archaeologist 11. Artifact / deployment expansion 12. Cross-project learning ``` The actual order should be chosen by Sol + V1 Archaeologist based on the state of the repository at that point. --- # 70. Final Bootstrap Principle The V1 engineering strategy is: > **Do not manually build the whole platform. Build the smallest trustworthy autonomous engineering system that can help build the rest.** The master specification describes the destination. This bootstrap specification defines the machine that starts the journey. # 71. Bootstrap Hooks for Roadmap, Explorer and Scenario Lab V1 does not need full Explorer or Scenario Lab implementations. However, V1 should include enough project-model structure that V2 can add them without schema redesign. Add minimal generic primitives: ```text roadmap_items findings scenarios ``` These may initially have no advanced UI. --- # 72. V1 Roadmap Schema Add a minimal `roadmap_items` model. Fields: ```text id project_id title description source status priority created_at updated_at ``` Recommended statuses: ```text INBOX NOW NEXT LATER EXPLORING DECLINED DONE ``` V1 may expose a simple Roadmap tab. No AI curation is required for bootstrap. --- # 73. V1 Finding Model Create a generic Finding artifact usable later by: ```text Steward Scenario Lab Explorer Reviewers Judges Security tools ``` Fields: ```text id project_id source type severity title description evidence status created_at ``` This prevents V2 from needing separate incompatible finding systems. --- # 74. V1 Scenario Registry Hook Add a minimal Scenario model/interface. Fields: ```text id project_id nullable name target_type target_id definition status created_at ``` V1 does not need automatic scenario generation or execution. A placeholder service interface is sufficient: ```python class ScenarioRunner: async def run(self, scenario_id): raise NotImplementedError ``` --- # 75. V1 Opportunity / Explorer Hook Do not implement a full Explorer in V1. Add an `opportunity` source type to Roadmap items and Findings. The Project Brain API should permit a future: ```text explore_project(project_id) ``` capability without changing the Project Plan or Project Brain data model. --- # 76. V1 Finished-Project Action Model V1 UI may only enable: ```text Open ``` for finished projects. But define action identifiers for future compatibility: ```text REPAIR EXTEND EVOLVE EXPLORE SCENARIO_LAB ROADMAP ``` These should not be hard-coded into lifecycle logic in a way that requires schema migration later. --- # 77. V1 Bootstrap Self-Build Candidates Update Good V2 features for V1 to build itself now include: ```text Roadmap UI Explorer workflow Scenario Lab execution Full Steward Extend Project Evolution campaigns Agent Control Room expansion Policy/workflow Progeny ``` This makes Explorer / Scenario Lab / Roadmap excellent self-bootstrap targets after the V1 core is stable.