29 KiB
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:
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:
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:
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:
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:
1. New Project
2. Archaeologist
New Project
Idea
↓
Sol Planning Chat
↓
Structured Project Plan
↓
Send to Builder
↓
Build
Archaeologist
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:
PLANNING
READY
ARCHAEOLOGY
BUILDING
PAUSING
PAUSED
BLOCKED
VERIFYING
FINISHED
FAILED
Optional placeholders may exist for:
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:
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:
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:
goal
scope
technical stack
architecture
features
constraints
acceptance criteria
permissions
resource budget
open decisions
UI concept:
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:
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:
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:
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:
requirement
confidence
evidence
status
Example:
{
"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:
Archaeologist
↓
Evidence / Findings
↓
Sol Archaeologist Chat
Sol and the user refine:
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:
DETERMINISTIC CONTROL PLANE
AGENT DECISION LAYER
VERIFICATION LAYER
Deterministic control plane owns:
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:
DISCOVER
PLAN
EXECUTE
VERIFY
Default permissions:
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:
PROJECT
↓
MILESTONE
↓
FEATURE
↓
TASK
↓
ACTION
Milestones are stable anchors.
Tasks remain dynamic.
19. Milestones
Every Project Plan should create initial milestones.
Example:
M1 Control Plane
M2 Project Archaeologist
M3 Agent Registry
M4 Autonomous Build Loop
M5 Self-Bootstrap
A milestone has:
goal
dependencies
features
verification contract
status
20. Dynamic Task DAG
Tasks live in PostgreSQL.
Required fields:
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:
QUEUED
READY
RUNNING
WAITING_TOOL
REVIEW
BLOCKED
FAILED
COMPLETE
21. Runtime Graph
Use LangGraph for the relatively stable execution graph.
Example:
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.
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:
class LangGraphRuntime(GraphRuntime):
...
23. Event Bus
V1 needs a persisted Event Bus.
Core events:
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:
UI activity stream
Scheduler
Project Brain
Metrics
Progeny
Notifications
24. Project Knowledge Graph
Implement a minimal Project Knowledge Graph.
Minimum node classes:
File
Symbol
Test
Task
Milestone
Requirement
Decision
Commit
Agent
Artifact
Minimum edges:
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:
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:
Project Archaeologist
Planner
Coder
Reviewer
Project Judge
Optional:
UI Designer
Django Architect
Security Reviewer
27. Agent Definition
Each agent version stores:
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:
Sol Agent Design Chat
↓
Structured Agent Plan
↓
Candidate Agent
↓
Benchmark
↓
Independent Evaluation
↓
Champion v1
Example:
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:
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:
Overview
Definition
Runs
Versions
Benchmarks
Failures
Chat
Show:
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:
agent system contract
context policy
workflow
model choice
V1 does not need broad autonomous policy evolution.
32. Progeny Champion / Challenger
Agent Champion
↓
Create Challenger
↓
Replay Benchmark Tasks
↓
Compare
↓
Promote / Reject
Minimum metrics:
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:
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:
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:
Task
↓
Create worktree
↓
Execute
↓
Tests
↓
Review
↓
Commit
↓
Integrate
Store task ↔ worktree ↔ branch ↔ commit lineage.
36. Tool Runtime
Minimum tools:
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:
read_repository
write_worktree
run_tests
create_branch
commit_changes
browser_test
High-risk capabilities remain unavailable in V1:
deploy_production
delete_production_data
arbitrary secret access
unrestricted host filesystem
38. Global Secret Registry
V1 should include a minimal Global Secret Registry.
Examples:
GitHub token
model API key
Hugging Face token
AWS / Bedrock credentials
Rules:
register once
grant per project/tool
never put raw secrets into prompts
inject at tool execution time
audit usage
UI:
Settings
└── Secrets
39. Global Resource Registry
V1 should model reusable resources:
Models
Secrets
Compute
Git
Artifact Storage
Example:
Models
GPT-5.6 Sol
Qwen 27B
Compute
DGX Spark
Git
GitHub
Projects reference resources rather than duplicating configuration.
40. Model Router
Minimum routing:
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:
request
agent
project
priority
model
token budget
status
Advanced GPU scheduling is V2.
42. Multi-Level Verification
V1 verification levels:
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:
FINISHED
43. Reviewer vs Judge
Reviewer:
reviews implementation quality
finds issues
requests changes
Judge:
decides whether an acceptance contract is satisfied
PASS / FAIL
The implementing agent may never self-certify completion.
44. Project Dashboard
Home screen:
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:
Overview
Chat
Plan
Graph
Agents
Activity
Tests
Git
Decisions
46. Overview
Show:
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:
M4 Autonomous Build Loop
│
├── Task Scheduler
├── Worktree Manager
├── Coder Worker
├── Reviewer
└── Integration
Clicking a node shows:
contract
dependencies
agent
tool calls
changed files
tests
review
commit
runtime
tokens
48. Activity Stream
Persist and display Event Bus events.
Example:
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:
stop scheduling new tasks
allow safe atomic operations to finish
persist runtime state
persist graph checkpoint
mark PAUSED
Resume:
reload state
validate worktrees
reconcile incomplete actions
return valid tasks to READY
continue
50. Decision Log
Record significant Project Brain/user decisions.
Fields:
decision_id
type
decision
reason
evidence
project plan version
timestamp
actor
Workers retrieve relevant decisions during context construction.
51. Artifact Registry
V1 artifact types:
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:
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:
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:
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:
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:
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:
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:
projects persist
plans persist
events persist
tasks persist
agents persist
dashboard renders
M2 — Autonomous Task Loop
Complete when:
task selected
worktree created
Coder modifies code
tests run
Reviewer reviews
Judge passes/rejects
commit recorded
M3 — Planning
Complete when:
Sol planning chat
creates structured Project Plan
and task DAG
M4 — Archaeologist
Complete when:
existing repo inspected
Git history analyzed
Observed/Inferred specs produced
Sol receives archaeology context
M5 — Agent Registry / Progeny
Complete when:
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:
Observed V1 capabilities
Missing master-spec capabilities
Architecture gaps
Likely V2 priorities
Step 4
Open Sol Project Brain chat.
User and Sol define:
V2 scope
milestones
acceptance criteria
budget
Step 5
Select:
Send to Builder
Step 6
V1 autonomously:
creates V2 task DAG
creates isolated worktrees
implements tasks
runs tests
reviews changes
verifies milestones
commits accepted work
Step 7
V1 produces:
candidate/v2
with:
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:
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:
≥ 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:
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:
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:
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
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:
Open
Pause
Resume
Stop
After verified completion:
Open
Extend, Evolve, and full Steward unlock in V2.
The underlying schema may anticipate them.
67. V1 Agent Actions
Required:
New Agent
Open Agent
Fork Agent
Create Challenger
Benchmark Challenger
Promote / Reject
Optional V1 UX aliases:
Extend Agent
Evolve Agent
These may initially map to Sol-guided Challenger creation.
68. Definition of V1 Done
V1 is DONE when:
✓ 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:
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:
roadmap_items
findings
scenarios
These may initially have no advanced UI.
72. V1 Roadmap Schema
Add a minimal roadmap_items model.
Fields:
id
project_id
title
description
source
status
priority
created_at
updated_at
Recommended statuses:
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:
Steward
Scenario Lab
Explorer
Reviewers
Judges
Security tools
Fields:
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:
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:
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:
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:
Open
for finished projects.
But define action identifiers for future compatibility:
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:
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.