Artifex/docs/artifex_v1_bootstrap_spec.md

# 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.