mirror of
https://github.com/fabro-sh/fabro.git
synced 2026-09-06 08:18:58 +00:00
cleanup workflows
This commit is contained in:
Bryan Helmkamp
parent
3a4743e10a
commit
f6cf39a6ea
61 changed files with 1 additions and 2194 deletions
|
|
@ -1,12 +0,0 @@
|
|||
digraph DaytonaCheck {
|
||||
graph [goal="Run cargo test in a Daytona sandbox and summarize results"]
|
||||
rankdir=LR
|
||||
|
||||
start [shape=Mdiamond, label="Start"]
|
||||
exit [shape=Msquare, label="Exit"]
|
||||
|
||||
run_tests [label="Run Tests", shape=parallelogram, script="cargo test --workspace 2>&1 || true"]
|
||||
report [label="Report", prompt="Summarize the test results"]
|
||||
|
||||
start -> run_tests -> report -> exit
|
||||
}
|
||||
|
|
@ -1,34 +0,0 @@
|
|||
version = 1
|
||||
goal = "Run cargo check in a Daytona cloud sandbox"
|
||||
graph = "check.fabro"
|
||||
|
||||
[llm]
|
||||
model = "claude-sonnet"
|
||||
|
||||
[sandbox]
|
||||
provider = "daytona"
|
||||
|
||||
[sandbox.env]
|
||||
CARGO_INCREMENTAL = "0"
|
||||
|
||||
[sandbox.daytona]
|
||||
auto_stop_interval = 60
|
||||
|
||||
[sandbox.daytona.labels]
|
||||
project = "attractor-rust"
|
||||
|
||||
[sandbox.daytona.snapshot]
|
||||
name = "attractor-rust-check-dev"
|
||||
cpu = 4
|
||||
memory = 8
|
||||
disk = 10
|
||||
dockerfile = """
|
||||
FROM rust:1.85-slim-bookworm
|
||||
RUN apt-get update && apt-get install -y --no-install-recommends \
|
||||
pkg-config libssl-dev cmake git curl ca-certificates ripgrep \
|
||||
&& rm -rf /var/lib/apt/lists/*
|
||||
RUN rustup update stable && rustup default stable
|
||||
RUN useradd -m -s /bin/bash daytona
|
||||
USER daytona
|
||||
WORKDIR /home/daytona
|
||||
"""
|
||||
|
|
@ -1,156 +0,0 @@
|
|||
# Software Factory Pipelines
|
||||
|
||||
Six Attractor pipelines that implement a spec-driven software factory. Markdown docs are the source of truth — code is a derived artifact.
|
||||
|
||||
## Document Structure
|
||||
|
||||
The factory operates on three layers:
|
||||
|
||||
1. **Product** — what to build (requirements, acceptance criteria)
|
||||
2. **Architecture** — how to build it (blueprints, diagrams, stack decisions)
|
||||
3. **Code** — the implementation (derived from the first two)
|
||||
|
||||
The first two layers are markdown docs. The third is generated from them.
|
||||
|
||||
```
|
||||
files-internal/
|
||||
product/ Layer 1: WHAT to build
|
||||
business-problem.md
|
||||
personas.md
|
||||
product-description.md
|
||||
current-state.md
|
||||
success-metrics.md
|
||||
technical-requirements.md
|
||||
features/
|
||||
NNN-feature.md per-feature requirements + acceptance criteria
|
||||
|
||||
architecture/ Layer 2: HOW to build it
|
||||
foundation-blueprints/
|
||||
backend.md stack-wide backend decisions
|
||||
data-layer.md stack-wide data decisions
|
||||
frontend.md stack-wide frontend decisions
|
||||
system-diagrams/
|
||||
entity-relationship-diagram.md
|
||||
sequence-diagram.md
|
||||
system-architecture.md
|
||||
features/
|
||||
NNN-feature.md per-feature blueprint (data model, API, UI)
|
||||
|
||||
src/ Layer 3: the implementation (generated)
|
||||
```
|
||||
|
||||
## Pipelines
|
||||
|
||||
### 1. Seed
|
||||
|
||||
Bootstrap product context from raw inputs. Run once per product.
|
||||
|
||||
**Input:** Conversations, notes, designs, existing code — anything unstructured.
|
||||
**Output:** Filled `product/` docs.
|
||||
|
||||
|
||||
|
||||
[seed.fabro](seed.fabro) | Prompts: [ingest](prompts/seed/ingest.md), [draft](prompts/seed/draft.md)
|
||||
|
||||
---
|
||||
|
||||
### 2. Specify
|
||||
|
||||
Define what a feature does in implementation-agnostic terms. Run once per feature.
|
||||
|
||||
**Input:** Product context docs + a feature idea (passed as `goal`).
|
||||
**Output:** `product/features/NNN-feature.md` with user stories and acceptance criteria.
|
||||
|
||||
|
||||
|
||||
[specify.fabro](specify.fabro) | Prompts: [clarify](prompts/specify/clarify.md), [require](prompts/specify/require.md)
|
||||
|
||||
---
|
||||
|
||||
### 3. Architect
|
||||
|
||||
Translate approved requirements into a technical blueprint. Run once per feature, after Specify.
|
||||
|
||||
**Input:** `product/features/NNN-feature.md` + foundation blueprints + codebase.
|
||||
**Output:** `architecture/features/NNN-feature.md` + updated system diagrams.
|
||||
|
||||
|
||||
|
||||
[architect.fabro](architect.fabro) | Prompts: [blueprint](prompts/architect/blueprint.md), [diagram](prompts/architect/diagram.md)
|
||||
|
||||
---
|
||||
|
||||
### 4. Implement
|
||||
|
||||
Generate working code from a feature blueprint. Run once per feature, after Architect. No human gate — the blueprint is the approved plan, and the validate/fix loop converges autonomously.
|
||||
|
||||
**Input:** Feature blueprint + foundation blueprints + codebase.
|
||||
**Output:** Committed code (migrations, models, API, UI, tests).
|
||||
|
||||
|
||||
|
||||
[implement.fabro](implement.fabro) | Prompts: [plan](prompts/implement/plan.md), [implement](prompts/implement/implement.md), [validate](prompts/implement/validate.md), [fix](prompts/implement/fix.md)
|
||||
|
||||
All nodes share `fidelity="full"` with `thread_id="impl"` so the agent maintains full context across the loop. `goal_gate=true` on Validate ensures the pipeline cannot exit until all acceptance criteria pass.
|
||||
|
||||
---
|
||||
|
||||
### 5. Sync
|
||||
|
||||
Detect and resolve drift between the three layers. Run continuously (after merges, on schedule, or on demand).
|
||||
|
||||
**Input:** A change to any layer (code, product docs, or architecture docs).
|
||||
**Output:** Updated docs or code that restore alignment.
|
||||
|
||||
|
||||
|
||||
[sync.fabro](sync.fabro) | Prompts: [detect](prompts/sync/detect.md), [propose](prompts/sync/propose.md), [apply](prompts/sync/apply.md)
|
||||
|
||||
Short-circuits to Exit when no drift is detected, avoiding unnecessary human interaction.
|
||||
|
||||
---
|
||||
|
||||
### 6. Expand
|
||||
|
||||
Evolve the product by adding, modifying, or removing features. Run as needed.
|
||||
|
||||
**Input:** Human intent (passed as `goal`), e.g. "split feature X" or "add Y".
|
||||
**Output:** Updated document tree, ready for Implement.
|
||||
|
||||
|
||||
|
||||
[expand.fabro](expand.fabro) | Prompts: [propose](prompts/expand/propose.md), [execute](prompts/expand/execute.md)
|
||||
|
||||
---
|
||||
|
||||
## How They Compose
|
||||
|
||||
```
|
||||
Seed ──→ Specify ──→ Architect ──→ Implement
|
||||
(1x) (1x per (1x per (1x per
|
||||
feature) feature) feature)
|
||||
↕ ↕ ↕
|
||||
Sync ←────── Sync ←────── Sync
|
||||
(continuous)
|
||||
↕
|
||||
Expand
|
||||
(as needed)
|
||||
```
|
||||
|
||||
- **Seed** runs once to bootstrap product context
|
||||
- **Specify** and **Architect** run once per feature to produce requirements and blueprints
|
||||
- **Implement** runs once per feature to produce code
|
||||
- **Sync** runs continuously to keep all three layers aligned
|
||||
- **Expand** runs when the product evolves (new features, splits, removals)
|
||||
|
||||
The docs are always the source of truth. If you delete all code and run Implement for every feature, you get the system back.
|
||||
|
||||
## Prompt References
|
||||
|
||||
DOT files reference prompts with `@`-style paths relative to the DOT file:
|
||||
|
||||
```dot
|
||||
plan [label="Plan Implementation", prompt="@prompts/implement/plan.md"]
|
||||
```
|
||||
|
||||
The `@` prefix tells the engine to read the file contents as the prompt. Prompts support `$goal` variable expansion.
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
digraph architect {
|
||||
graph [
|
||||
goal="",
|
||||
label="Architect"
|
||||
]
|
||||
rankdir=LR
|
||||
|
||||
start [shape=Mdiamond, label="Start"]
|
||||
exit [shape=Msquare, label="Exit"]
|
||||
|
||||
blueprint [label="Write Blueprint", prompt="@prompts/architect/blueprint.md", reasoning_effort="high"]
|
||||
diagram [label="Update Diagrams", prompt="@prompts/architect/diagram.md"]
|
||||
approve [shape=hexagon, label="Approve Architecture"]
|
||||
|
||||
start -> blueprint -> diagram -> approve
|
||||
approve -> exit [label="[A] Accept"]
|
||||
approve -> blueprint [label="[R] Revise"]
|
||||
}
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 27 KiB |
|
|
@ -1,19 +0,0 @@
|
|||
digraph expand {
|
||||
graph [
|
||||
goal="",
|
||||
label="Expand"
|
||||
]
|
||||
rankdir=LR
|
||||
|
||||
start [shape=Mdiamond, label="Start"]
|
||||
exit [shape=Msquare, label="Exit"]
|
||||
|
||||
propose [label="Propose Changes", prompt="@prompts/expand/propose.md", reasoning_effort="high"]
|
||||
approve [shape=hexagon, label="Approve Changes"]
|
||||
execute [label="Execute Changes", prompt="@prompts/expand/execute.md"]
|
||||
|
||||
start -> propose -> approve
|
||||
approve -> execute [label="[A] Accept"]
|
||||
approve -> propose [label="[R] Revise"]
|
||||
execute -> exit
|
||||
}
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 20 KiB |
|
|
@ -1,33 +0,0 @@
|
|||
digraph implement {
|
||||
graph [
|
||||
goal="",
|
||||
label="Implement"
|
||||
]
|
||||
rankdir=LR
|
||||
|
||||
start [shape=Mdiamond, label="Start"]
|
||||
exit [shape=Msquare, label="Exit"]
|
||||
|
||||
strategy [shape=hexagon, label="Choose decomposition strategy:"]
|
||||
|
||||
subgraph cluster_impl {
|
||||
label="Implementation Loop"
|
||||
node [fidelity="full", thread_id="impl"]
|
||||
|
||||
plan [label="Plan Implementation", prompt="@prompts/implement/plan.md", reasoning_effort="high"]
|
||||
implement [label="Implement", prompt="@prompts/implement/implement.md"]
|
||||
review [label="Review", prompt="@prompts/implement/review.md"]
|
||||
validate [label="Validate", prompt="@prompts/implement/validate.md", goal_gate=true]
|
||||
fix [label="Fix Failures", prompt="@prompts/implement/fix.md", max_visits=3]
|
||||
}
|
||||
|
||||
start -> strategy
|
||||
strategy -> plan [label="[L] Layer-by-layer"]
|
||||
strategy -> plan [label="[F] Feature slice"]
|
||||
strategy -> plan [label="[P] Embarrassingly parallel"]
|
||||
strategy -> plan [label="[S] Sequential / linear"]
|
||||
plan -> implement -> review -> validate
|
||||
validate -> exit [condition="outcome=success"]
|
||||
validate -> fix [condition="outcome!=success", label="Fix"]
|
||||
fix -> validate
|
||||
}
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 29 KiB |
|
|
@ -1,37 +0,0 @@
|
|||
Read the feature requirements doc matching $goal under files-internal/product/features/.
|
||||
Read the foundation blueprints under files-internal/architecture/foundation-blueprints/ (backend.md, data-layer.md, frontend.md).
|
||||
Read all existing feature blueprints under files-internal/architecture/features/.
|
||||
Read the current codebase structure.
|
||||
|
||||
Write the feature blueprint at files-internal/architecture/features/ with:
|
||||
|
||||
## Solution Design
|
||||
|
||||
High-level technical architecture for this feature.
|
||||
|
||||
## Key Design Decisions
|
||||
|
||||
Rationale for approach choices, referencing foundation blueprint conventions.
|
||||
|
||||
## Data Model
|
||||
|
||||
Entities, fields, types, relationships. Reference existing tables from other blueprints. Define new tables where needed.
|
||||
|
||||
## API Implementation
|
||||
|
||||
Endpoints, HTTP methods, request/response models. Follow foundation backend conventions (FastAPI, SQLModel, dependency injection).
|
||||
|
||||
## UI Implementation
|
||||
|
||||
Key components, states, interactions. Use foundation frontend stack (React, shadcn/ui, Tailwind).
|
||||
|
||||
## Out of Scope
|
||||
|
||||
Adjacent concerns, optimizations, or features explicitly excluded from this blueprint. The implementing agent must not address anything listed here.
|
||||
|
||||
The blueprint must be detailed enough for an agent to implement without further clarification.
|
||||
|
||||
Before completing, self-verify:
|
||||
- Every acceptance criterion from the feature requirements is addressed by at least one section
|
||||
- Nothing in the blueprint contradicts the foundation blueprints
|
||||
- The Out of Scope section explicitly excludes adjacent concerns that an implementing agent might drift into
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
Read the feature blueprint just written and the current system diagrams under files-internal/architecture/system-diagrams/.
|
||||
|
||||
Update only the diagrams that need changes:
|
||||
- **entity-relationship-diagram.md**: Add new entities and relationships from the data model section
|
||||
- **sequence-diagram.md**: Add new API flows from the API implementation section
|
||||
- **system-architecture.md**: Add new components from the solution design section
|
||||
|
||||
Preserve all existing diagram content. Only add or modify what this feature requires. If no diagram changes are needed, leave them unchanged.
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
Execute the approved change manifest:
|
||||
|
||||
- For new features: create the product feature doc and architecture feature blueprint following the standard templates under files-internal/product/features/ and files-internal/architecture/features/
|
||||
- For modified features: update the existing product and architecture docs with the specified changes
|
||||
- For removed features: delete the product and architecture docs, note affected code for cleanup
|
||||
- For diagram changes: update the system diagrams under files-internal/architecture/system-diagrams/
|
||||
|
||||
Ensure all docs remain internally consistent after changes.
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
Read all product docs under files-internal/product/, all architecture docs under files-internal/architecture/, and the current codebase.
|
||||
|
||||
The requested change: $goal
|
||||
|
||||
Analyze how this change affects the existing product, then propose a concrete change manifest:
|
||||
|
||||
For each affected feature:
|
||||
- **NEW:** Feature docs to create (product/features/ and architecture/features/) with a one-paragraph description
|
||||
- **MODIFY:** Existing docs to update with specific changes described
|
||||
- **REMOVE:** Features to deprecate or remove with cleanup plan
|
||||
- **DIAGRAM:** System diagrams to update
|
||||
|
||||
For each affected feature, also note:
|
||||
- **OUT OF SCOPE:** Related changes that should not be made as part of this expansion
|
||||
|
||||
Present the manifest as an ordered list of actions.
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
Read the validation failures from the previous step.
|
||||
|
||||
For each failing acceptance criterion:
|
||||
- Identify the root cause in the implementation
|
||||
- Fix the code to satisfy the criterion
|
||||
- Re-run the relevant tests
|
||||
|
||||
Do not change the feature requirements or blueprint. Only fix the implementation.
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
Execute the implementation plan step by step.
|
||||
|
||||
For each step:
|
||||
- Create or modify the specified files
|
||||
- Follow the conventions in the foundation blueprints
|
||||
- Write tests alongside implementation
|
||||
- Ensure each step builds on the previous one
|
||||
|
||||
Do not deviate from the feature blueprint. Do not implement anything listed in the blueprint's Out of Scope section. If the blueprint is ambiguous, make the simplest choice that satisfies the acceptance criteria.
|
||||
|
||||
Before completing, self-verify:
|
||||
- Every acceptance criterion has corresponding implementation and tests
|
||||
- No code was added for anything in the blueprint's Out of Scope section
|
||||
- New code follows the conventions in the foundation blueprints
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
Read the feature blueprint matching $goal under files-internal/architecture/features/.
|
||||
Read the foundation blueprints under files-internal/architecture/foundation-blueprints/.
|
||||
Read the acceptance criteria from the matching doc under files-internal/product/features/.
|
||||
Read the relevant existing source code.
|
||||
|
||||
Decomposition strategy: $context.human.gate.label
|
||||
|
||||
Decompose the blueprint into ordered implementation steps using the chosen strategy:
|
||||
|
||||
- **Layer-by-layer:** Group steps by technical layer — database migrations, then data models, then API endpoints, then UI components, then tests for each layer.
|
||||
- **Feature slice:** Group steps by user-facing capability — each step delivers a vertical slice from database through UI for one piece of functionality.
|
||||
- **Embarrassingly parallel:** Identify steps with no dependencies on each other and group them for concurrent implementation. Mark dependency ordering explicitly.
|
||||
- **Sequential / linear:** One step per logical change, strictly ordered, each building on the previous.
|
||||
|
||||
For each step, specify the exact files to create or modify and what changes to make.
|
||||
|
||||
Do not plan work for anything listed in the blueprint's Out of Scope section. Every step must trace to an acceptance criterion.
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
Review the implementation with fresh eyes. You did not write this code.
|
||||
|
||||
Read the feature blueprint matching $goal under files-internal/architecture/features/.
|
||||
Read the implementation files created or modified by the previous step.
|
||||
|
||||
Evaluate the code for:
|
||||
- **Correctness:** Logic errors, off-by-one mistakes, unhandled edge cases
|
||||
- **Security:** Injection risks, unsafe input handling, exposed secrets
|
||||
- **Consistency:** Does it follow the patterns in the foundation blueprints and surrounding codebase?
|
||||
- **Duplication:** Unnecessary copy-paste that should be extracted
|
||||
- **Simplicity:** Overly complex code that could be simpler without losing clarity
|
||||
|
||||
Do not rewrite the code. Report specific issues with file and line references.
|
||||
|
||||
If no significant issues are found, return SUCCESS.
|
||||
If issues are found, return FAIL with a numbered list of issues to fix.
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
Read the acceptance criteria from the feature requirements doc matching $goal under files-internal/product/features/.
|
||||
|
||||
For each acceptance criterion (AC-NNN-XXX.N):
|
||||
- Verify the implementation satisfies "When [condition], the system shall [behavior]"
|
||||
- Run relevant tests
|
||||
- Check that the code matches the feature blueprint's data model, API, and UI specs
|
||||
|
||||
Report:
|
||||
- PASS or FAIL for each acceptance criterion
|
||||
- Overall satisfaction score (passed / total)
|
||||
- Specific gaps or failures with file and line references
|
||||
|
||||
Return SUCCESS only if all acceptance criteria pass.
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
Using the ingested artifacts, write the following product documents under files-internal/product/:
|
||||
|
||||
1. **business-problem.md** — The problem this product solves, who it affects, why existing solutions fall short
|
||||
2. **personas.md** — Target user types with goals, pain points, and usage patterns
|
||||
3. **product-description.md** — What the product is, core value proposition, key capabilities
|
||||
4. **current-state.md** — What exists today, what works, what doesn't
|
||||
5. **success-metrics.md** — How we measure whether the product is succeeding
|
||||
6. **technical-requirements.md** — Cross-cutting constraints: security, performance, integrations, compliance
|
||||
|
||||
Be specific and concrete. Where information is missing, state assumptions clearly. Every requirement must be testable.
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
Read all provided artifacts in the working directory: notes, transcripts, designs, existing source code, README files, and any other documentation.
|
||||
|
||||
Extract:
|
||||
- Core themes and product concepts
|
||||
- Contradictions or ambiguities
|
||||
- Gaps in understanding
|
||||
- Technical constraints mentioned
|
||||
- User types referenced
|
||||
|
||||
Summarize findings. Identify what product context is still missing.
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
Read all product context docs under files-internal/product/ and all existing feature docs under files-internal/product/features/.
|
||||
|
||||
The feature to specify: $goal
|
||||
|
||||
Analyze the feature idea against existing product context. Identify:
|
||||
- Which personas this feature serves
|
||||
- How it relates to existing features (dependencies, overlaps)
|
||||
- Scope boundaries: what is in and what is out
|
||||
- Edge cases and constraints from technical-requirements.md
|
||||
- Open questions that need answers before writing requirements
|
||||
|
||||
Prepare a scope summary for the next step.
|
||||
|
|
@ -1,26 +0,0 @@
|
|||
Write the feature requirements document at files-internal/product/features/ following the template structure:
|
||||
|
||||
## Overview
|
||||
|
||||
Clear summary of what the feature does and the value it delivers.
|
||||
|
||||
## Terminology
|
||||
|
||||
Key terms with definitions.
|
||||
|
||||
## Requirements
|
||||
|
||||
For each requirement:
|
||||
- **REQ-NNN-XXX:** Named requirement
|
||||
- **User Story:** As a [persona], I want to [action], so that I can [outcome]
|
||||
- **Acceptance Criteria:** AC-NNN-XXX.N: When [condition], the system shall [behavior]
|
||||
|
||||
## Out of Scope
|
||||
|
||||
Adjacent capabilities, integrations, or behaviors explicitly excluded from this feature. Downstream agents must not implement anything listed here.
|
||||
|
||||
## Feature Behavior & Rules
|
||||
|
||||
Cross-requirement interactions, defaults, constraints, edge conditions.
|
||||
|
||||
Keep requirements implementation-agnostic. No data models, API shapes, or UI components. Focus only on observable behavior that a user or test can verify.
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
Apply the approved changes. Update the specified files in the specified layers.
|
||||
|
||||
Ensure all three layers are consistent after changes are applied:
|
||||
- Product feature docs match observable behavior
|
||||
- Feature blueprints match actual data models, APIs, and UI
|
||||
- System diagrams reflect current entities, flows, and components
|
||||
- Foundation blueprints reflect actual stack conventions
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
Read all three layers and compare for alignment:
|
||||
|
||||
1. **Product docs:** files-internal/product/ (all feature requirements and acceptance criteria)
|
||||
2. **Architecture docs:** files-internal/architecture/ (foundation blueprints, feature blueprints, system diagrams)
|
||||
3. **Source code:** the actual implementation
|
||||
|
||||
For each feature, check:
|
||||
- Do acceptance criteria in product/features/ match what the code actually does?
|
||||
- Does the feature blueprint match the current code structure (data model, API, UI)?
|
||||
- Do system diagrams reflect the current entities, flows, and components?
|
||||
- Are foundation blueprints consistent with actual tech stack usage?
|
||||
|
||||
Report all mismatches with:
|
||||
- Which layer is the source of truth (most recently intentionally changed)
|
||||
- What needs to be updated
|
||||
- The specific files and sections affected
|
||||
|
||||
Set context.drift_found to true if any drift detected, false otherwise.
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
Based on the drift detected, propose specific changes to restore alignment.
|
||||
|
||||
For each mismatch:
|
||||
- Identify which layer to update: prefer updating docs to match intentional code changes, prefer updating code to match intentional doc changes
|
||||
- Write the exact changes: file path, what to add, modify, or remove
|
||||
- Explain why this direction of sync was chosen
|
||||
|
||||
Group changes by layer (product docs, architecture docs, code) for review.
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
digraph seed {
|
||||
graph [
|
||||
goal="Bootstrap product context documentation from raw inputs",
|
||||
label="Seed"
|
||||
]
|
||||
rankdir=LR
|
||||
|
||||
start [shape=Mdiamond, label="Start"]
|
||||
exit [shape=Msquare, label="Exit"]
|
||||
|
||||
ingest [label="Ingest Artifacts", prompt="@prompts/seed/ingest.md", reasoning_effort="high"]
|
||||
draft [label="Draft Product Docs", prompt="@prompts/seed/draft.md"]
|
||||
review [shape=hexagon, label="Review Product Docs"]
|
||||
|
||||
start -> ingest -> draft -> review
|
||||
review -> exit [label="[A] Accept"]
|
||||
review -> draft [label="[R] Revise"]
|
||||
}
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 21 KiB |
|
|
@ -1,18 +0,0 @@
|
|||
digraph specify {
|
||||
graph [
|
||||
goal="",
|
||||
label="Specify"
|
||||
]
|
||||
rankdir=LR
|
||||
|
||||
start [shape=Mdiamond, label="Start"]
|
||||
exit [shape=Msquare, label="Exit"]
|
||||
|
||||
clarify [label="Clarify Scope", prompt="@prompts/specify/clarify.md", reasoning_effort="high"]
|
||||
require [label="Write Requirements", prompt="@prompts/specify/require.md", reasoning_effort="high"]
|
||||
approve [shape=hexagon, label="Approve Requirements"]
|
||||
|
||||
start -> clarify -> require -> approve
|
||||
approve -> exit [label="[A] Accept"]
|
||||
approve -> require [label="[R] Revise"]
|
||||
}
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 26 KiB |
|
|
@ -1,23 +0,0 @@
|
|||
digraph sync {
|
||||
graph [
|
||||
goal="Detect and resolve drift between product docs, architecture docs, and code",
|
||||
label="Sync"
|
||||
]
|
||||
rankdir=LR
|
||||
|
||||
start [shape=Mdiamond, label="Start"]
|
||||
exit [shape=Msquare, label="Exit"]
|
||||
|
||||
detect [label="Detect Drift", prompt="@prompts/sync/detect.md", reasoning_effort="high"]
|
||||
propose [label="Propose Changes", prompt="@prompts/sync/propose.md"]
|
||||
review [shape=hexagon, label="Review Changes"]
|
||||
apply [label="Apply Changes", prompt="@prompts/sync/apply.md"]
|
||||
|
||||
start -> detect
|
||||
detect -> exit [condition="context.drift_found=false", label="No drift"]
|
||||
detect -> propose [condition="context.drift_found=true", label="Drift found"]
|
||||
propose -> review
|
||||
review -> apply [label="[A] Accept"]
|
||||
review -> propose [label="[R] Revise"]
|
||||
apply -> exit
|
||||
}
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 39 KiB |
|
|
@ -1,64 +0,0 @@
|
|||
FROM node:22-bookworm-slim
|
||||
|
||||
RUN apt-get update && apt-get install -y --no-install-recommends \
|
||||
curl jq git ca-certificates \
|
||||
&& rm -rf /var/lib/apt/lists/*
|
||||
|
||||
RUN printf '%s\n' \
|
||||
'#!/usr/bin/env bash' \
|
||||
'set -euo pipefail' \
|
||||
'' \
|
||||
'usage() {' \
|
||||
' echo "Usage: imagegen <prompt> [output.png]" >&2' \
|
||||
' echo "" >&2' \
|
||||
' echo "Generate an image from a text prompt using OpenAI gpt-image-1." >&2' \
|
||||
' echo "Output defaults to '"'"'output.png'"'"' if not specified." >&2' \
|
||||
' exit 1' \
|
||||
'}' \
|
||||
'' \
|
||||
'if [[ $# -lt 1 ]] || [[ "${1:-}" == "--help" ]] || [[ "${1:-}" == "-h" ]]; then' \
|
||||
' usage' \
|
||||
'fi' \
|
||||
'' \
|
||||
'if [[ -z "${OPENAI_API_KEY:-}" ]]; then' \
|
||||
' echo "Error: OPENAI_API_KEY not set" >&2' \
|
||||
' exit 1' \
|
||||
'fi' \
|
||||
'' \
|
||||
'PROMPT="$1"' \
|
||||
'OUTPUT="${2:-output.png}"' \
|
||||
'MODEL="${IMAGEGEN_MODEL:-gpt-image-1}"' \
|
||||
'API_URL="https://api.openai.com/v1/images/generations"' \
|
||||
'' \
|
||||
'echo "Generating image for: ${PROMPT}" >&2' \
|
||||
'echo "Model: ${MODEL}" >&2' \
|
||||
'' \
|
||||
'RESPONSE=$(curl -s --fail-with-body -X POST "$API_URL" \' \
|
||||
' -H "Content-Type: application/json" \' \
|
||||
' -H "Authorization: Bearer ${OPENAI_API_KEY}" \' \
|
||||
' -d "$(jq -n --arg prompt "$PROMPT" --arg model "$MODEL" '"'"'{' \
|
||||
' model: $model,' \
|
||||
' prompt: $prompt,' \
|
||||
' n: 1,' \
|
||||
' size: "1024x1024"' \
|
||||
' }'"'"')")' \
|
||||
'' \
|
||||
'ERROR=$(echo "$RESPONSE" | jq -r '"'"'.error.message // empty'"'"')' \
|
||||
'if [[ -n "$ERROR" ]]; then' \
|
||||
' echo "API error: $ERROR" >&2' \
|
||||
' exit 1' \
|
||||
'fi' \
|
||||
'' \
|
||||
'IMAGE_DATA=$(echo "$RESPONSE" | jq -r '"'"'.data[0].b64_json // empty'"'"')' \
|
||||
'' \
|
||||
'if [[ -z "$IMAGE_DATA" ]]; then' \
|
||||
' echo "No image in response. Raw:" >&2' \
|
||||
' echo "$RESPONSE" | jq . >&2' \
|
||||
' exit 1' \
|
||||
'fi' \
|
||||
'' \
|
||||
'echo "$IMAGE_DATA" | base64 -d > "$OUTPUT"' \
|
||||
'echo "Saved to ${OUTPUT}" >&2' \
|
||||
> /usr/local/bin/imagegen && chmod +x /usr/local/bin/imagegen
|
||||
|
||||
WORKDIR /root
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
Use the /develop-web-game skill and the `imagegen` CLI tool.
|
||||
|
||||
Create a hyperrealistic interactive 3D experience of the San Francisco Golden Gate Bridge that the user can fly around freely. The environment should include realistic lighting, water, fog, atmosphere, suspension cables, traffic, surrounding coastline, and city context, with a cinematic sense of scale and detail. Let the user smoothly navigate through the scene with intuitive flight controls and multiple viewpoints, including close-up structural passes and wide scenic flyovers. Prioritize realism, immersion, and visual fidelity.
|
||||
|
||||
Use `imagegen` to generate source material and surface textures. For example:
|
||||
```
|
||||
imagegen "photorealistic golden gate bridge tower close-up, red steel, rivets, fog" output/textures/tower.png
|
||||
imagegen "san francisco bay water surface, realistic ocean waves, sunlight reflections" output/textures/water.png
|
||||
```
|
||||
|
||||
When playtesting with Playwright, fly around the bridge from multiple distances and angles, verify that navigation is smooth and stable, and confirm that the world looks convincing both up close and from afar. The result should look high fidelity and smooth, almost like a photo — not clunky or block-like. There should be realistic cars going over the bridge too.
|
||||
|
||||
Take your time and iterate until the experience is polished.
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
digraph GoldenGate {
|
||||
graph [
|
||||
goal="Create a hyperrealistic interactive 3D Golden Gate Bridge flight experience",
|
||||
model_stylesheet="* { model: gpt-5.4;}"
|
||||
]
|
||||
rankdir=LR
|
||||
|
||||
start [shape=Mdiamond, label="Start"]
|
||||
exit [shape=Msquare, label="Exit"]
|
||||
|
||||
build [label="Build Experience", prompt="@prompt.md"]
|
||||
|
||||
start -> build -> exit
|
||||
}
|
||||
|
|
@ -1,35 +0,0 @@
|
|||
version = 1
|
||||
goal = "Create a hyperrealistic interactive 3D Golden Gate Bridge flight experience"
|
||||
graph = "workflow.fabro"
|
||||
|
||||
[llm]
|
||||
model = "gpt-5.4"
|
||||
|
||||
[sandbox]
|
||||
provider = "daytona"
|
||||
|
||||
[sandbox.env]
|
||||
OPENAI_API_KEY = "${env.OPENAI_API_KEY}"
|
||||
|
||||
[sandbox.daytona]
|
||||
auto_stop_interval = 30
|
||||
|
||||
[sandbox.daytona.labels]
|
||||
project = "golden-gate"
|
||||
|
||||
[sandbox.daytona.snapshot]
|
||||
name = "golden-gate-v3"
|
||||
cpu = 4
|
||||
memory = 8
|
||||
disk = 10
|
||||
dockerfile = { path = "Dockerfile.golden-gate" }
|
||||
|
||||
[assets]
|
||||
include = ["output/**"]
|
||||
|
||||
[mcp_servers.playwright]
|
||||
type = "sandbox"
|
||||
command = ["npx", "@playwright/mcp@latest", "--port", "3100", "--headless", "--browser", "chromium"]
|
||||
port = 3100
|
||||
startup_timeout_secs = 60
|
||||
tool_timeout_secs = 120
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
digraph Hello {
|
||||
graph [goal="Say hello and demonstrate a basic Fabro workflow"]
|
||||
rankdir=LR
|
||||
|
||||
start [shape=Mdiamond, label="Start"]
|
||||
exit [shape=Msquare, label="Exit"]
|
||||
|
||||
greet [label="Greet", prompt="Say hello! Introduce yourself and explain that this is a test of the fabro workflow engine."]
|
||||
|
||||
start -> greet -> exit
|
||||
}
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
version = 1
|
||||
graph = "workflow.fabro"
|
||||
|
||||
[sandbox]
|
||||
provider = "local"
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
digraph ImageGenOpenAI {
|
||||
rankdir=LR
|
||||
|
||||
start [shape=Mdiamond, label="Start"]
|
||||
exit [shape=Msquare, label="Exit"]
|
||||
|
||||
generate [label="Generate Image", prompt="Generate an image of: $goal\n\nRun: mkdir -p output && imagegen \"$goal\" output/generated.png\n\nThen verify the file exists with: ls -la output/generated.png"]
|
||||
|
||||
start -> generate -> exit
|
||||
}
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
version = 1
|
||||
graph = "workflow.fabro"
|
||||
|
||||
[sandbox]
|
||||
provider = "daytona"
|
||||
|
||||
[sandbox.env]
|
||||
OPENAI_API_KEY = "${env.OPENAI_API_KEY}"
|
||||
|
||||
[sandbox.daytona.snapshot]
|
||||
name = "imagegen-openai-v1"
|
||||
cpu = 4
|
||||
memory = 8
|
||||
disk = 10
|
||||
dockerfile = { path = "../golden-gate/Dockerfile.golden-gate" }
|
||||
|
||||
[assets]
|
||||
include = ["output/**"]
|
||||
|
|
@ -1,69 +0,0 @@
|
|||
FROM ubuntu:22.04
|
||||
RUN apt-get update && apt-get install -y --no-install-recommends \
|
||||
curl jq git ca-certificates \
|
||||
&& rm -rf /var/lib/apt/lists/*
|
||||
|
||||
RUN printf '%s\n' \
|
||||
'#!/usr/bin/env bash' \
|
||||
'set -euo pipefail' \
|
||||
'' \
|
||||
'usage() {' \
|
||||
' echo "Usage: imagegen <prompt> [output.png]" >&2' \
|
||||
' echo "" >&2' \
|
||||
' echo "Generate an image from a text prompt using Gemini." >&2' \
|
||||
' echo "Output defaults to '"'"'output.png'"'"' if not specified." >&2' \
|
||||
' exit 1' \
|
||||
'}' \
|
||||
'' \
|
||||
'if [[ $# -lt 1 ]] || [[ "${1:-}" == "--help" ]] || [[ "${1:-}" == "-h" ]]; then' \
|
||||
' usage' \
|
||||
'fi' \
|
||||
'' \
|
||||
'if [[ -z "${GEMINI_API_KEY:-}" ]]; then' \
|
||||
' echo "Error: GEMINI_API_KEY not set" >&2' \
|
||||
' exit 1' \
|
||||
'fi' \
|
||||
'' \
|
||||
'PROMPT="$1"' \
|
||||
'OUTPUT="${2:-output.png}"' \
|
||||
'MODEL="${IMAGEGEN_MODEL:-gemini-2.5-flash-image}"' \
|
||||
'API_URL="https://generativelanguage.googleapis.com/v1beta/models/${MODEL}:generateContent?key=${GEMINI_API_KEY}"' \
|
||||
'' \
|
||||
'echo "Generating image for: ${PROMPT}" >&2' \
|
||||
'echo "Model: ${MODEL}" >&2' \
|
||||
'' \
|
||||
'RESPONSE=$(curl -s -X POST "$API_URL" \' \
|
||||
' -H "Content-Type: application/json" \' \
|
||||
' -d "$(jq -n --arg prompt "$PROMPT" '"'"'{' \
|
||||
' contents: [{ parts: [{ text: $prompt }] }],' \
|
||||
' generationConfig: { responseModalities: ["TEXT", "IMAGE"] }' \
|
||||
' }'"'"')")' \
|
||||
'' \
|
||||
'ERROR=$(echo "$RESPONSE" | jq -r '"'"'.error.message // empty'"'"')' \
|
||||
'if [[ -n "$ERROR" ]]; then' \
|
||||
' echo "API error: $ERROR" >&2' \
|
||||
' exit 1' \
|
||||
'fi' \
|
||||
'' \
|
||||
'IMAGE_DATA=$(echo "$RESPONSE" | jq -r '"'"'' \
|
||||
' .candidates[0].content.parts[]' \
|
||||
' | select(.inlineData)' \
|
||||
' | .inlineData.data' \
|
||||
''"'"' | head -1)' \
|
||||
'' \
|
||||
'if [[ -z "$IMAGE_DATA" ]]; then' \
|
||||
' TEXT=$(echo "$RESPONSE" | jq -r '"'"'.candidates[0].content.parts[] | select(.text) | .text // empty'"'"')' \
|
||||
' if [[ -n "$TEXT" ]]; then' \
|
||||
' echo "Model response (no image): $TEXT" >&2' \
|
||||
' else' \
|
||||
' echo "No image in response. Raw:" >&2' \
|
||||
' echo "$RESPONSE" | jq . >&2' \
|
||||
' fi' \
|
||||
' exit 1' \
|
||||
'fi' \
|
||||
'' \
|
||||
'echo "$IMAGE_DATA" | base64 -d > "$OUTPUT"' \
|
||||
'echo "Saved to ${OUTPUT}" >&2' \
|
||||
> /usr/local/bin/imagegen && chmod +x /usr/local/bin/imagegen
|
||||
|
||||
WORKDIR /root
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
digraph ImageGen {
|
||||
graph [goal="A cute robot painting a landscape"]
|
||||
rankdir=LR
|
||||
|
||||
start [shape=Mdiamond, label="Start"]
|
||||
exit [shape=Msquare, label="Exit"]
|
||||
|
||||
generate [label="Generate Image", prompt="Generate an image of: $goal\n\nRun: mkdir -p output && imagegen \"$goal\" output/generated.png\n\nThen verify the file exists with: ls -la output/generated.png"]
|
||||
|
||||
start -> generate -> exit
|
||||
}
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
version = 1
|
||||
graph = "workflow.fabro"
|
||||
|
||||
[sandbox]
|
||||
provider = "daytona"
|
||||
|
||||
[sandbox.env]
|
||||
GEMINI_API_KEY = "${env.GEMINI_API_KEY}"
|
||||
|
||||
[assets]
|
||||
include = ["output/**"]
|
||||
|
||||
[sandbox.daytona.snapshot]
|
||||
name = "imagegen-tools-v6"
|
||||
cpu = 4
|
||||
memory = 8
|
||||
disk = 10
|
||||
dockerfile = { path = "Dockerfile.imagegen" }
|
||||
|
|
@ -1,46 +0,0 @@
|
|||
# Simplify: Code Review and Cleanup
|
||||
|
||||
Review all changed files for reuse, quality, and efficiency. Fix any issues found.
|
||||
|
||||
## Phase 1: Identify Changes
|
||||
|
||||
Run git diff (or git diff HEAD if there are staged changes) to see what changed. If there are no git changes, review the most recently modified files that the user mentioned or that you edited earlier in this conversation.
|
||||
|
||||
## Phase 2: Launch Three Review Agents in Parallel
|
||||
|
||||
Use the Agent tool to launch all three agents concurrently in a single message. Pass each agent the full diff so it has the complete context.
|
||||
|
||||
### Agent 1: Code Reuse Review
|
||||
|
||||
For each change:
|
||||
|
||||
1. Search for existing utilities and helpers that could replace newly written code. Use Grep to find similar patterns elsewhere in the codebase — common locations are utility directories, shared modules, and files adjacent to the changed ones.
|
||||
2. Flag any new function that duplicates existing functionality. Suggest the existing function to use instead.
|
||||
3. Flag any inline logic that could use an existing utility — hand-rolled string manipulation, manual path handling, custom environment checks, ad-hoc type guards, and similar patterns are common candidates.
|
||||
|
||||
### Agent 2: Code Quality Review
|
||||
|
||||
Review the same changes for hacky patterns:
|
||||
|
||||
1. Redundant state: state that duplicates existing state, cached values that could be derived, observers/effects that could be direct calls
|
||||
2. Parameter sprawl: adding new parameters to a function instead of generalizing or restructuring existing ones
|
||||
3. Copy-paste with slight variation: near-duplicate code blocks that should be unified with a shared abstraction
|
||||
4. Leaky abstractions: exposing internal details that should be encapsulated, or breaking existing abstraction boundaries
|
||||
5. Stringly-typed code: using raw strings where constants, enums (string unions), or branded types already exist in the codebase
|
||||
|
||||
### Agent 3: Efficiency Review
|
||||
|
||||
Review the same changes for efficiency:
|
||||
|
||||
1. Unnecessary work: redundant computations, repeated file reads, duplicate network/API calls, N+1 patterns
|
||||
2. Missed concurrency: independent operations run sequentially when they could run in parallel
|
||||
3. Hot-path bloat: new blocking work added to startup or per-request/per-render hot paths
|
||||
4. Unnecessary existence checks: pre-checking file/resource existence before operating (TOCTOU anti-pattern) — operate directly and handle the error
|
||||
5. Memory: unbounded data structures, missing cleanup, event listener leaks
|
||||
6. Overly broad operations: reading entire files when only a portion is needed, loading all items when filtering for one
|
||||
|
||||
## Phase 3: Fix Issues
|
||||
|
||||
Wait for all three agents to complete. Aggregate their findings and fix each issue directly. If a finding is a false positive or not worth addressing, note it and move on — do not argue with the finding, just skip it.
|
||||
|
||||
When done, briefly summarize what was fixed (or confirm the code was already clean).
|
||||
|
|
@ -1,15 +1 @@
|
|||
version = 1
|
||||
graph = "workflow.fabro"
|
||||
|
||||
[sandbox]
|
||||
provider = "local"
|
||||
# provider = "daytona"
|
||||
|
||||
# [sandbox.env]
|
||||
# CARGO_INCREMENTAL = "0"
|
||||
|
||||
# [sandbox.daytona.snapshot]
|
||||
# name = "daytona-large"
|
||||
|
||||
[sandbox.local]
|
||||
worktree_mode = "always"
|
||||
version = 1
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
You have Playwright MCP tools available. Do the following:
|
||||
|
||||
1. First, call the `browser_install` tool to ensure the browser is installed.
|
||||
2. Create the screenshots directory: `mkdir -p /home/daytona/workspace/screenshots`
|
||||
3. Use `browser_navigate` to go to https://news.ycombinator.com
|
||||
4. Use `browser_snapshot` to capture the page content
|
||||
5. Use `browser_take_screenshot` to save a screenshot to `/home/daytona/workspace/screenshots/01-hn-front-page.png`
|
||||
6. Click on the first story link
|
||||
7. Use `browser_take_screenshot` to save a screenshot to `/home/daytona/workspace/screenshots/02-first-story.png`
|
||||
8. Use `browser_navigate_back` to go back to the front page
|
||||
9. Click on the "new" link in the nav bar
|
||||
10. Use `browser_take_screenshot` to save a screenshot to `/home/daytona/workspace/screenshots/03-newest.png`
|
||||
|
||||
After capturing screenshots, write a brief summary of what you found on Hacker News today.
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
digraph PlaywrightDemo {
|
||||
graph [goal="Use Playwright MCP to browse Hacker News and take screenshots", model_stylesheet="* { model: claude-sonnet-4-6;}"]
|
||||
rankdir=LR
|
||||
|
||||
start [shape=Mdiamond, label="Start"]
|
||||
exit [shape=Msquare, label="Exit"]
|
||||
|
||||
install_browser [label="Install Browser", shape=parallelogram, script="npx playwright install --with-deps chromium 2>&1 || true"]
|
||||
|
||||
browse [label="Browse Hacker News", prompt="@browse-prompt.md"]
|
||||
|
||||
start -> install_browser -> browse -> exit
|
||||
}
|
||||
|
|
@ -1,28 +0,0 @@
|
|||
version = 1
|
||||
goal = "Browse Hacker News with Playwright MCP and capture screenshots"
|
||||
graph = "workflow.fabro"
|
||||
|
||||
[llm]
|
||||
model = "claude-sonnet-4-6"
|
||||
|
||||
[sandbox]
|
||||
provider = "daytona"
|
||||
|
||||
[sandbox.daytona]
|
||||
auto_stop_interval = 30
|
||||
|
||||
[sandbox.daytona.labels]
|
||||
project = "playwright-demo"
|
||||
|
||||
[sandbox.daytona.snapshot]
|
||||
name = "daytona-medium"
|
||||
|
||||
[assets]
|
||||
include = ["screenshots/**"]
|
||||
|
||||
[mcp_servers.playwright]
|
||||
type = "sandbox"
|
||||
command = ["npx", "@playwright/mcp@latest", "--port", "3100", "--headless", "--browser", "chromium"]
|
||||
port = 3100
|
||||
startup_timeout_secs = 60
|
||||
tool_timeout_secs = 120
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
digraph REPL {
|
||||
graph [goal="Interactive REPL: execute user prompts in a loop"]
|
||||
rankdir=LR
|
||||
|
||||
start [shape=Mdiamond, label="Start"]
|
||||
exit [shape=Msquare, label="Exit"]
|
||||
|
||||
prompt [shape=hexagon, label="Enter prompt"]
|
||||
agent [shape=tab, label="Agent", fidelity="summary:high", prompt="Execute the user's request. Their prompt is in the current context (human.gate.text) from the previous human gate. (Ignore diagnostic information about the pipeline and stages -- just talk normally to the user like a friendly assistant.)"]
|
||||
|
||||
start -> prompt
|
||||
prompt -> agent [freeform=true]
|
||||
agent -> prompt
|
||||
}
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
version = 1
|
||||
graph = "workflow.fabro"
|
||||
|
||||
[sandbox]
|
||||
provider = "local"
|
||||
|
||||
[sandbox.local]
|
||||
worktree_mode = "never"
|
||||
|
|
@ -1,170 +0,0 @@
|
|||
digraph BuildSolitaire {
|
||||
graph [
|
||||
goal="Build a terminal-based solitaire (Klondike) game in Python",
|
||||
rankdir=LR,
|
||||
default_max_retry=3,
|
||||
retry_target="impl_setup",
|
||||
fallback_retry_target="impl_logic",
|
||||
model_stylesheet="
|
||||
* { model: claude-sonnet;}
|
||||
.hard { model: claude-opus; }
|
||||
.verify { model: claude-haiku; }
|
||||
"
|
||||
]
|
||||
|
||||
start [shape=Mdiamond, label="Start"]
|
||||
exit [shape=Msquare, label="Exit"]
|
||||
|
||||
// Phase 0: Expand the goal into a detailed spec
|
||||
expand_spec [
|
||||
label="Expand Spec",
|
||||
prompt="Expand the goal into a detailed spec covering:\n\
|
||||
- Game rules and data structures (Card, Deck, Pile types)\n\
|
||||
- Terminal rendering approach (curses library)\n\
|
||||
- Input handling and move validation\n\
|
||||
- Win/loss detection\n\
|
||||
- UI layout\n\
|
||||
- Test strategy\n\n\
|
||||
Write the spec to spec.md."
|
||||
]
|
||||
|
||||
// Phase 1: Project setup
|
||||
impl_setup [
|
||||
label="Setup Project",
|
||||
prompt="Read spec.md. Create the Python project structure:\n\
|
||||
pyproject.toml, src/ directory, tests/ directory, main.py stub.\n\
|
||||
Run: python3 -m py_compile src/*.py"
|
||||
]
|
||||
|
||||
verify_setup [label="Verify Setup", class="verify",
|
||||
prompt="Verify project setup: check pyproject.toml exists,\n\
|
||||
source directories exist, and files compile without errors.\n\
|
||||
Run: python3 -m py_compile src/*.py"
|
||||
]
|
||||
|
||||
check_setup [shape=diamond, label="Setup OK?"]
|
||||
|
||||
// Phase 2: Core data structures
|
||||
impl_data [
|
||||
label="Data Structures",
|
||||
prompt="Read spec.md. Implement Card, Deck, and Pile types\n\
|
||||
with unit tests. Run: python3 -m pytest tests/ -v"
|
||||
]
|
||||
|
||||
verify_data [label="Verify Data", class="verify",
|
||||
prompt="Verify data structures: build, run tests, check that\n\
|
||||
Card, Deck, and Pile types are defined and basic operations work.\n\
|
||||
Run: python3 -m pytest tests/ -v"
|
||||
]
|
||||
|
||||
check_data [shape=diamond, label="Data OK?"]
|
||||
|
||||
// Phase 3: Game logic (hardest phase)
|
||||
impl_logic [
|
||||
label="Game Logic",
|
||||
class="hard",
|
||||
max_retries=2,
|
||||
prompt="Read spec.md and the data structure files.\n\
|
||||
Implement Klondike rules: initial deal, move validation,\n\
|
||||
auto-complete detection, win condition, undo.\n\
|
||||
Write tests for legal/illegal moves, win detection, edge cases.\n\
|
||||
Run: python3 -m pytest tests/ -v"
|
||||
]
|
||||
|
||||
verify_logic [label="Verify Logic", class="verify",
|
||||
prompt="Verify game logic: run all tests, check move validation,\n\
|
||||
win detection, and undo.\n\
|
||||
Run: python3 -m pytest tests/ -v"
|
||||
]
|
||||
|
||||
check_logic [shape=diamond, label="Logic OK?"]
|
||||
|
||||
// Phase 4: Terminal UI
|
||||
impl_ui [
|
||||
label="Terminal UI",
|
||||
class="hard",
|
||||
max_retries=2,
|
||||
prompt="Read spec.md and game logic files.\n\
|
||||
Implement terminal UI with curses: card rendering (ASCII art),\n\
|
||||
board layout, keyboard input, move selection, help text.\n\
|
||||
Run: python3 -m pytest tests/ && python3 -m py_compile src/*.py"
|
||||
]
|
||||
|
||||
verify_ui [label="Verify UI", class="verify",
|
||||
prompt="Verify terminal UI: build, run tests, check that\n\
|
||||
renderer and input handler exist, game can be instantiated.\n\
|
||||
Run: python3 -m pytest tests/"
|
||||
]
|
||||
|
||||
check_ui [shape=diamond, label="UI OK?"]
|
||||
|
||||
// Phase 5: Integration
|
||||
impl_integration [
|
||||
label="Integrate",
|
||||
prompt="Wire up main.py to start the game loop.\n\
|
||||
Connect UI input to game logic. Add game over screen,\n\
|
||||
help menu, and README with build/run instructions.\n\
|
||||
Run: python3 -m pytest tests/"
|
||||
]
|
||||
|
||||
verify_integration [label="Verify Integration", class="verify",
|
||||
prompt="Verify integration: build, run all tests, check README\n\
|
||||
exists, verify the game starts without errors.\n\
|
||||
Run: python3 -m pytest tests/"
|
||||
]
|
||||
|
||||
check_integration [shape=diamond, label="Integration OK?"]
|
||||
|
||||
// Phase 6: Final review (goal gate)
|
||||
review [
|
||||
label="Final Review",
|
||||
class="hard",
|
||||
goal_gate=true,
|
||||
prompt="Read spec.md in full. Review the complete implementation:\n\
|
||||
- All Klondike rules correctly implemented\n\
|
||||
- Terminal UI works and is intuitive\n\
|
||||
- Tests comprehensive and passing\n\
|
||||
- README clear and accurate\n\n\
|
||||
Run the full test suite. Write a review to review.md.\n\
|
||||
Run: python3 -m pytest tests/ -v"
|
||||
]
|
||||
|
||||
check_review [shape=diamond, label="Review OK?"]
|
||||
|
||||
// Wiring: linear phases with verify-gate loops
|
||||
start -> expand_spec -> impl_setup -> verify_setup -> check_setup
|
||||
|
||||
check_setup -> impl_data [condition="outcome=success"]
|
||||
check_setup -> impl_setup [condition="outcome=fail", label="Retry"]
|
||||
check_setup -> impl_setup
|
||||
|
||||
impl_data -> verify_data -> check_data
|
||||
|
||||
check_data -> impl_logic [condition="outcome=success"]
|
||||
check_data -> impl_data [condition="outcome=fail", label="Retry"]
|
||||
check_data -> impl_data
|
||||
|
||||
impl_logic -> verify_logic -> check_logic
|
||||
|
||||
check_logic -> impl_ui [condition="outcome=success"]
|
||||
check_logic -> impl_logic [condition="outcome=fail", label="Retry"]
|
||||
check_logic -> impl_logic
|
||||
|
||||
impl_ui -> verify_ui -> check_ui
|
||||
|
||||
check_ui -> impl_integration [condition="outcome=success"]
|
||||
check_ui -> impl_ui [condition="outcome=fail", label="Retry"]
|
||||
check_ui -> impl_ui
|
||||
|
||||
impl_integration -> verify_integration -> check_integration
|
||||
|
||||
check_integration -> review [condition="outcome=success"]
|
||||
check_integration -> impl_integration [condition="outcome=fail", label="Retry"]
|
||||
check_integration -> impl_integration
|
||||
|
||||
review -> check_review
|
||||
|
||||
check_review -> exit [condition="outcome=success"]
|
||||
check_review -> impl_ui [condition="outcome=fail", label="Fix"]
|
||||
check_review -> impl_ui
|
||||
}
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
version = 1
|
||||
graph = "workflow.fabro"
|
||||
|
|
@ -1,655 +0,0 @@
|
|||
digraph SpecDoDMultiModel {
|
||||
graph [
|
||||
goal="Satisfy every Definition of Done checkbox across all three attractor specs (unified-llm-spec.md, coding-agent-loop-spec.md, attractor-spec.md). The implementation is in Rust under crates/. Do NOT modify the spec files. Only modify implementation code. Uses multi-model consensus: Opus 4.6 and GPT-5.2 compete on audits and planning, GPT-5.2-codex and Opus 4.6 alternate on implementation.",
|
||||
default_max_retry="3",
|
||||
retry_target="triage_merge",
|
||||
default_fidelity="full",
|
||||
model_stylesheet="
|
||||
* { model: claude-opus-4-6;}
|
||||
.opus { model: claude-opus-4-6;reasoning_effort: high; }
|
||||
.gpt { model: gpt-5.2; reasoning_effort: high; }
|
||||
.codex { model: gpt-5.2-codex; reasoning_effort: high; }
|
||||
.merge { model: claude-opus-4-6; reasoning_effort: high; }
|
||||
"
|
||||
]
|
||||
|
||||
start [shape=Mdiamond]
|
||||
exit [shape=Msquare]
|
||||
|
||||
/*========================================================================
|
||||
* PHASE 1 — Dual Independent Audits (interleaved, fidelity-isolated)
|
||||
*
|
||||
* Each spec is audited by both models before moving to the next spec.
|
||||
* Audit nodes use fidelity="truncate" so they only see the graph goal
|
||||
* and NOT each other's responses — prevents anchoring bias.
|
||||
* Full responses are still stored as response.<node_id> for later use.
|
||||
*======================================================================*/
|
||||
|
||||
/* ---- LLM spec: both models ---- */
|
||||
|
||||
audit_llm_opus [
|
||||
label="Opus: Audit LLM DoD",
|
||||
shape=box,
|
||||
class="opus",
|
||||
fidelity="truncate",
|
||||
prompt="Read docs/specs/unified-llm-spec.md Section 8 (Definition of Done) in full. Then read every source file under crates/llm/src/.
|
||||
|
||||
For EACH checkbox in sections 8.1 through 8.10, evaluate whether the current Rust implementation satisfies it. Be strict — a checkbox is only checked if the feature is fully implemented and would work correctly at runtime.
|
||||
|
||||
Respond with ONLY a JSON object (no prose) -- don't write it out as a file:
|
||||
{
|
||||
\"spec\": \"unified-llm\",
|
||||
\"model\": \"opus\",
|
||||
\"sections\": {
|
||||
\"8.1\": { \"title\": \"Core Infrastructure\", \"items\": [ {\"text\": \"...\", \"pass\": true/false, \"reason\": \"...\"} ] },
|
||||
...
|
||||
},
|
||||
\"total\": N,
|
||||
\"passed\": M,
|
||||
\"failed\": K,
|
||||
\"failed_items\": [ {\"section\": \"8.2\", \"text\": \"...\", \"reason\": \"...\"} ]
|
||||
}
|
||||
|
||||
Be thorough. Check every single checkbox."
|
||||
]
|
||||
|
||||
audit_llm_gpt [
|
||||
label="GPT-5.2: Audit LLM DoD",
|
||||
shape=box,
|
||||
class="gpt",
|
||||
fidelity="truncate",
|
||||
prompt="Read docs/specs/unified-llm-spec.md Section 8 (Definition of Done) in full. Then read every source file under crates/llm/src/.
|
||||
|
||||
For EACH checkbox in sections 8.1 through 8.10, evaluate whether the current Rust implementation satisfies it. Be strict — a checkbox is only checked if the feature is fully implemented and would work correctly at runtime.
|
||||
|
||||
Respond with ONLY a JSON object (no prose) -- don't write it out as a file:
|
||||
{
|
||||
\"spec\": \"unified-llm\",
|
||||
\"model\": \"gpt-5.2\",
|
||||
\"sections\": {
|
||||
\"8.1\": { \"title\": \"Core Infrastructure\", \"items\": [ {\"text\": \"...\", \"pass\": true/false, \"reason\": \"...\"} ] },
|
||||
...
|
||||
},
|
||||
\"total\": N,
|
||||
\"passed\": M,
|
||||
\"failed\": K,
|
||||
\"failed_items\": [ {\"section\": \"8.2\", \"text\": \"...\", \"reason\": \"...\"} ]
|
||||
}
|
||||
|
||||
Be thorough. Check every single checkbox."
|
||||
]
|
||||
|
||||
/* ---- Agent spec: both models ---- */
|
||||
|
||||
audit_agent_opus [
|
||||
label="Opus: Audit Agent DoD",
|
||||
shape=box,
|
||||
class="opus",
|
||||
fidelity="truncate",
|
||||
prompt="Read docs/specs/coding-agent-loop-spec.md Section 9 (Definition of Done) in full. Then read every source file under crates/agent/.
|
||||
|
||||
For EACH checkbox in sections 9.1 through 9.13, evaluate whether the current Rust implementation satisfies it. Be strict.
|
||||
|
||||
Respond with ONLY a JSON object (no prose) -- don't write it out as a file:
|
||||
{
|
||||
\"spec\": \"coding-agent-loop\",
|
||||
\"model\": \"opus\",
|
||||
\"sections\": { ... },
|
||||
\"total\": N,
|
||||
\"passed\": M,
|
||||
\"failed\": K,
|
||||
\"failed_items\": [ {\"section\": \"9.1\", \"text\": \"...\", \"reason\": \"...\"} ]
|
||||
}
|
||||
|
||||
Be thorough. Check every single checkbox."
|
||||
]
|
||||
|
||||
audit_agent_gpt [
|
||||
label="GPT-5.2: Audit Agent DoD",
|
||||
shape=box,
|
||||
class="gpt",
|
||||
fidelity="truncate",
|
||||
prompt="Read docs/specs/coding-agent-loop-spec.md Section 9 (Definition of Done) in full. Then read every source file under crates/agent/.
|
||||
|
||||
For EACH checkbox in sections 9.1 through 9.13, evaluate whether the current Rust implementation satisfies it. Be strict.
|
||||
|
||||
Respond with ONLY a JSON object (no prose) -- don't write it out as a file:
|
||||
{
|
||||
\"spec\": \"coding-agent-loop\",
|
||||
\"model\": \"gpt-5.2\",
|
||||
\"sections\": { ... },
|
||||
\"total\": N,
|
||||
\"passed\": M,
|
||||
\"failed\": K,
|
||||
\"failed_items\": [ {\"section\": \"9.1\", \"text\": \"...\", \"reason\": \"...\"} ]
|
||||
}
|
||||
|
||||
Be thorough. Check every single checkbox."
|
||||
]
|
||||
|
||||
/* ---- Attractor spec: both models ---- */
|
||||
|
||||
audit_attractor_opus [
|
||||
label="Opus: Audit Attractor DoD",
|
||||
shape=box,
|
||||
class="opus",
|
||||
fidelity="truncate",
|
||||
prompt="Read docs/specs/attractor-spec.md Section 11 (Definition of Done) in full. Then read every source file under crates/attractor/.
|
||||
|
||||
For EACH checkbox in sections 11.1 through 11.13, evaluate whether the current Rust implementation satisfies it. Be strict.
|
||||
|
||||
Respond with ONLY a JSON object (no prose) -- don't write it out as a file:
|
||||
{
|
||||
\"spec\": \"attractor\",
|
||||
\"model\": \"opus\",
|
||||
\"sections\": { ... },
|
||||
\"total\": N,
|
||||
\"passed\": M,
|
||||
\"failed\": K,
|
||||
\"failed_items\": [ {\"section\": \"11.1\", \"text\": \"...\", \"reason\": \"...\"} ]
|
||||
}
|
||||
|
||||
Be thorough. Check every single checkbox."
|
||||
]
|
||||
|
||||
audit_attractor_gpt [
|
||||
label="GPT-5.2: Audit Attractor DoD",
|
||||
shape=box,
|
||||
class="gpt",
|
||||
fidelity="truncate",
|
||||
prompt="Read docs/specs/attractor-spec.md Section 11 (Definition of Done) in full. Then read every source file under crates/attractor/.
|
||||
|
||||
For EACH checkbox in sections 11.1 through 11.13, evaluate whether the current Rust implementation satisfies it. Be strict.
|
||||
|
||||
Respond with ONLY a JSON object (no prose) -- don't write it out as a file:
|
||||
{
|
||||
\"spec\": \"attractor\",
|
||||
\"model\": \"gpt-5.2\",
|
||||
\"sections\": { ... },
|
||||
\"total\": N,
|
||||
\"passed\": M,
|
||||
\"failed\": K,
|
||||
\"failed_items\": [ {\"section\": \"11.1\", \"text\": \"...\", \"reason\": \"...\"} ]
|
||||
}
|
||||
|
||||
Be thorough. Check every single checkbox."
|
||||
]
|
||||
|
||||
/*========================================================================
|
||||
* PHASE 2 — Cross-Critique (fidelity=full to see all response.* keys)
|
||||
*
|
||||
* Each model reviews the other's audit. Like megaplan's Compete phase:
|
||||
* independent work first, then adversarial review.
|
||||
*======================================================================*/
|
||||
|
||||
critique_by_gpt [
|
||||
label="GPT-5.2: Critique Opus Audits",
|
||||
shape=box,
|
||||
class="gpt",
|
||||
fidelity="full",
|
||||
prompt="You have all six audit reports available in context. The full outputs are in these context keys:
|
||||
|
||||
OPUS AUDITS:
|
||||
- response.audit_llm_opus — Opus's audit of unified-llm-spec.md Section 8
|
||||
- response.audit_agent_opus — Opus's audit of coding-agent-loop-spec.md Section 9
|
||||
- response.audit_attractor_opus — Opus's audit of attractor-spec.md Section 11
|
||||
|
||||
GPT AUDITS (your own):
|
||||
- response.audit_llm_gpt — your audit of unified-llm-spec.md Section 8
|
||||
- response.audit_agent_gpt — your audit of coding-agent-loop-spec.md Section 9
|
||||
- response.audit_attractor_gpt — your audit of attractor-spec.md Section 11
|
||||
|
||||
Compare them item by item. For every DoD checkbox where the two models DISAGREE (one says pass, the other says fail), re-read the relevant spec section and source file to determine who is correct.
|
||||
|
||||
Also identify items that one model flagged but the other missed entirely.
|
||||
|
||||
Respond with JSON (not by writing out a file):
|
||||
{
|
||||
\"agreements\": { \"both_pass\": N, \"both_fail\": N },
|
||||
\"disagreements\": [
|
||||
{
|
||||
\"spec\": \"...\", \"section\": \"...\", \"text\": \"...\",
|
||||
\"opus_says\": \"pass|fail\", \"gpt_says\": \"pass|fail\",
|
||||
\"verdict\": \"pass|fail\",
|
||||
\"reasoning\": \"...\"
|
||||
}
|
||||
],
|
||||
\"missed_by_opus\": [ {\"spec\": \"...\", \"section\": \"...\", \"text\": \"...\", \"reason\": \"...\"} ],
|
||||
\"missed_by_gpt\": [ {\"spec\": \"...\", \"section\": \"...\", \"text\": \"...\", \"reason\": \"...\"} ]
|
||||
}
|
||||
|
||||
Be rigorous. When in doubt, fail the checkbox — strictness prevents false confidence."
|
||||
]
|
||||
|
||||
critique_by_opus [
|
||||
label="Opus: Critique GPT-5.2 Audits",
|
||||
shape=box,
|
||||
class="opus",
|
||||
fidelity="full",
|
||||
prompt="You have all six audit reports available in context. The full outputs are in these context keys:
|
||||
|
||||
GPT AUDITS:
|
||||
- response.audit_llm_gpt — GPT-5.2's audit of unified-llm-spec.md Section 8
|
||||
- response.audit_agent_gpt — GPT-5.2's audit of coding-agent-loop-spec.md Section 9
|
||||
- response.audit_attractor_gpt — GPT-5.2's audit of attractor-spec.md Section 11
|
||||
|
||||
OPUS AUDITS (your own):
|
||||
- response.audit_llm_opus — your audit of unified-llm-spec.md Section 8
|
||||
- response.audit_agent_opus — your audit of coding-agent-loop-spec.md Section 9
|
||||
- response.audit_attractor_opus — your audit of attractor-spec.md Section 11
|
||||
|
||||
Compare them item by item. For every DoD checkbox where the two models DISAGREE (one says pass, the other says fail), re-read the relevant spec section and source file to determine who is correct.
|
||||
|
||||
Also identify items that one model flagged but the other missed entirely.
|
||||
|
||||
Respond with JSON (not by writing out a file):
|
||||
{
|
||||
\"agreements\": { \"both_pass\": N, \"both_fail\": N },
|
||||
\"disagreements\": [
|
||||
{
|
||||
\"spec\": \"...\", \"section\": \"...\", \"text\": \"...\",
|
||||
\"opus_says\": \"pass|fail\", \"gpt_says\": \"pass|fail\",
|
||||
\"verdict\": \"pass|fail\",
|
||||
\"reasoning\": \"...\"
|
||||
}
|
||||
],
|
||||
\"missed_by_opus\": [ {\"spec\": \"...\", \"section\": \"...\", \"text\": \"...\", \"reason\": \"...\"} ],
|
||||
\"missed_by_gpt\": [ {\"spec\": \"...\", \"section\": \"...\", \"text\": \"...\", \"reason\": \"...\"} ]
|
||||
}
|
||||
|
||||
Be rigorous. When in doubt, fail the checkbox — strictness prevents false confidence."
|
||||
]
|
||||
|
||||
/*========================================================================
|
||||
* PHASE 3 — Audit Consensus
|
||||
*
|
||||
* Merge all findings into a single agreed-upon truth.
|
||||
* Like megaplan's Merge phase: best ideas from both, disagreements resolved.
|
||||
*======================================================================*/
|
||||
|
||||
audit_consensus [
|
||||
label="Merge: Audit Consensus",
|
||||
shape=box,
|
||||
class="merge",
|
||||
fidelity="full",
|
||||
prompt="You have all prior audit and critique outputs in context. The key inputs are:
|
||||
|
||||
SIX AUDIT REPORTS (context keys response.audit_llm_opus, response.audit_agent_opus, response.audit_attractor_opus, response.audit_llm_gpt, response.audit_agent_gpt, response.audit_attractor_gpt)
|
||||
|
||||
TWO CROSS-CRITIQUES (context keys response.critique_by_gpt, response.critique_by_opus)
|
||||
|
||||
Produce a single definitive audit result. Resolution rules:
|
||||
1. If BOTH models agree a checkbox passes → pass
|
||||
2. If BOTH models agree a checkbox fails → fail
|
||||
3. If they DISAGREE, use the cross-critique verdicts. If the critiques also disagree, re-read the spec and code yourself and make the call. When in doubt, fail it.
|
||||
4. Include any items that were missed by one model but caught by the other.
|
||||
|
||||
Respond with JSON (not by writing out a file):
|
||||
{
|
||||
\"spec_results\": {
|
||||
\"unified-llm\": { \"total\": N, \"passed\": M, \"failed\": K, \"failed_items\": [...] },
|
||||
\"coding-agent-loop\": { ... },
|
||||
\"attractor\": { ... }
|
||||
},
|
||||
\"consensus_total\": N,
|
||||
\"consensus_passed\": M,
|
||||
\"consensus_failed\": K,
|
||||
\"disagreements_resolved\": N,
|
||||
\"all_failed_items\": [ {\"spec\": \"...\", \"section\": \"...\", \"text\": \"...\", \"reason\": \"...\", \"agreed_by\": \"both|opus_only|gpt_only|resolved\"} ]
|
||||
}"
|
||||
]
|
||||
|
||||
/*========================================================================
|
||||
* PHASE 4 — Dual Triage
|
||||
*
|
||||
* Both models independently prioritize the failures, then merge.
|
||||
* Different models weight different risks differently — consensus is stronger.
|
||||
*======================================================================*/
|
||||
|
||||
triage_opus [
|
||||
label="Opus: Triage & Prioritize",
|
||||
shape=box,
|
||||
class="opus",
|
||||
fidelity="full",
|
||||
prompt="The consensus audit results are in context key response.audit_consensus. Parse the all_failed_items list from that JSON and triage every failing DoD checkbox.
|
||||
|
||||
Group failures into:
|
||||
1. IMPLEMENTABLE — can be fixed by writing/modifying Rust code (functions, handlers, logic)
|
||||
2. STRUCTURAL — requires new files, new modules, or significant architecture changes
|
||||
3. DEFERRED — requires external resources (real API keys, network access, interactive testing) that cannot be done in a code-only pass
|
||||
|
||||
For each IMPLEMENTABLE item, identify the exact file(s) to modify and briefly describe the fix. Rank them by impact (most important first).
|
||||
|
||||
Respond with JSON (not by writing out a file):
|
||||
{
|
||||
\"model\": \"opus\",
|
||||
\"total_failing\": N,
|
||||
\"implementable\": [ {\"rank\": 1, \"spec\": \"...\", \"section\": \"...\", \"text\": \"...\", \"files\": [\"...\"], \"fix\": \"...\", \"impact\": \"high|medium|low\"} ],
|
||||
\"structural\": [ ... ],
|
||||
\"deferred\": [ ... ]
|
||||
}"
|
||||
]
|
||||
|
||||
triage_gpt [
|
||||
label="GPT-5.2: Triage & Prioritize",
|
||||
shape=box,
|
||||
class="gpt",
|
||||
fidelity="full",
|
||||
prompt="The consensus audit results are in context key response.audit_consensus. Parse the all_failed_items list from that JSON and triage every failing DoD checkbox.
|
||||
|
||||
Group failures into:
|
||||
1. IMPLEMENTABLE — can be fixed by writing/modifying Rust code (functions, handlers, logic)
|
||||
2. STRUCTURAL — requires new files, new modules, or significant architecture changes
|
||||
3. DEFERRED — requires external resources (real API keys, network access, interactive testing) that cannot be done in a code-only pass
|
||||
|
||||
For each IMPLEMENTABLE item, identify the exact file(s) to modify and briefly describe the fix. Rank them by impact (most important first).
|
||||
|
||||
Respond with JSON (not by writing out a file):
|
||||
{
|
||||
\"model\": \"gpt-5.2\",
|
||||
\"total_failing\": N,
|
||||
\"implementable\": [ {\"rank\": 1, \"spec\": \"...\", \"section\": \"...\", \"text\": \"...\", \"files\": [\"...\"], \"fix\": \"...\", \"impact\": \"high|medium|low\"} ],
|
||||
\"structural\": [ ... ],
|
||||
\"deferred\": [ ... ]
|
||||
}"
|
||||
]
|
||||
|
||||
triage_merge [
|
||||
label="Merge: Triage Consensus",
|
||||
shape=box,
|
||||
class="merge",
|
||||
fidelity="full",
|
||||
prompt="You have two triage reports in context: response.triage_opus and response.triage_gpt. Merge them into a single prioritized work plan.
|
||||
|
||||
Resolution rules:
|
||||
1. If both models classify an item the same way (IMPLEMENTABLE/STRUCTURAL/DEFERRED) → keep that classification
|
||||
2. If they disagree on classification → take the MORE ACTIONABLE classification (prefer IMPLEMENTABLE over STRUCTURAL over DEFERRED)
|
||||
3. For ranking, average the ranks and re-sort. If one model identified files/fixes the other didn't, include all suggestions.
|
||||
4. Deduplicate items that both models identified.
|
||||
|
||||
Respond with JSON (not by writing out a file):
|
||||
{
|
||||
\"total_failing\": N,
|
||||
\"implementable\": [ {\"spec\": \"...\", \"section\": \"...\", \"text\": \"...\", \"files\": [\"...\"], \"fix\": \"...\", \"opus_rank\": N, \"gpt_rank\": N} ],
|
||||
\"structural\": [ ... ],
|
||||
\"deferred\": [ ... ],
|
||||
\"classification_disagreements\": N,
|
||||
\"verdict\": \"all_clear\" | \"has_fixes\" | \"only_deferred\"
|
||||
}
|
||||
|
||||
If total_failing == 0 or verdict == \"only_deferred\", set preferred_next_label to \"Done\".
|
||||
Otherwise set preferred_next_label to \"Fix\"."
|
||||
]
|
||||
|
||||
/*========================================================================
|
||||
* PHASE 5 — Multi-Model Implementation
|
||||
*
|
||||
* Codex implements, Opus reviews and corrects, Codex validates.
|
||||
* Like megaplan's draft→critique→merge but for code.
|
||||
*======================================================================*/
|
||||
|
||||
fix_codex [
|
||||
label="Codex: Implement Fixes",
|
||||
shape=box,
|
||||
class="codex",
|
||||
goal_gate=true,
|
||||
fidelity="full",
|
||||
prompt="The merged triage report is in context key response.triage_merge. It contains a prioritized list of IMPLEMENTABLE DoD failures.
|
||||
|
||||
Pick the top 5 most impactful items (or all if fewer than 5) and implement the fixes in Rust.
|
||||
|
||||
Begin by making sure the build is green with `cargo test`
|
||||
|
||||
For each fix:
|
||||
1. Read the relevant source file(s)
|
||||
2. Make the minimal change needed to satisfy the DoD checkbox
|
||||
3. Write the modified file(s) -- update tests as needed
|
||||
4. Verify the fix and the tests pass (`cargo test`)
|
||||
|
||||
Constraints:
|
||||
- Do NOT modify any files under docs/specs/ (those are the specs)
|
||||
- Do NOT add external dependencies beyond what's already used
|
||||
- Keep changes minimal and focused — one checkbox per fix
|
||||
- Maintain the existing code style
|
||||
|
||||
Respond with JSON (not by writing out a file):
|
||||
{
|
||||
\"model\": \"codex\",
|
||||
\"fixes_applied\": [ {\"spec\": \"...\", \"section\": \"...\", \"text\": \"...\", \"files_changed\": [\"...\"], \"description\": \"...\"} ],
|
||||
\"count\": N,
|
||||
\"remaining_implementable\": M
|
||||
}"
|
||||
]
|
||||
|
||||
review_fix_opus [
|
||||
label="Opus: Review & Fix",
|
||||
shape=box,
|
||||
class="opus",
|
||||
goal_gate=true,
|
||||
fidelity="full",
|
||||
prompt="Codex just implemented a batch of fixes. Its report is in context key response.fix_codex.
|
||||
|
||||
PART A — Review Codex's work:
|
||||
1. Read every file that Codex modified (check the files_changed lists in response.fix_codex)
|
||||
2. For each fix, verify it actually satisfies the DoD checkbox it claims to address
|
||||
3. Check for: correctness, edge cases, style consistency, missing error handling
|
||||
4. If a fix is wrong or incomplete, rewrite it correctly
|
||||
|
||||
PART B — Implement additional fixes:
|
||||
5. From the remaining IMPLEMENTABLE items (see response.triage_merge for the full list), pick up to 5 more and implement them
|
||||
6. Follow the same constraints as Codex (Rust, no new deps, minimal changes)
|
||||
|
||||
Respond with JSON (not by writing out a file):
|
||||
{
|
||||
\"model\": \"opus\",
|
||||
\"codex_fixes_reviewed\": N,
|
||||
\"codex_fixes_correct\": N,
|
||||
\"codex_fixes_corrected\": [ {\"spec\": \"...\", \"section\": \"...\", \"issue\": \"...\", \"correction\": \"...\"} ],
|
||||
\"additional_fixes\": [ {\"spec\": \"...\", \"section\": \"...\", \"text\": \"...\", \"files_changed\": [\"...\"], \"description\": \"...\"} ],
|
||||
\"total_fixes_this_round\": N,
|
||||
\"remaining_implementable\": M
|
||||
}"
|
||||
]
|
||||
|
||||
review_codex [
|
||||
label="Codex: Validate All Changes",
|
||||
shape=box,
|
||||
class="codex",
|
||||
fidelity="full",
|
||||
prompt="Opus reviewed your fixes and implemented additional ones. Its report is in context key response.review_fix_opus. Your original report is in response.fix_codex.
|
||||
|
||||
Validate the full set of changes from this round:
|
||||
1. Read every file modified in this round (check files_changed in both response.fix_codex and response.review_fix_opus)
|
||||
2. Check each change for correctness: does it satisfy its DoD checkbox?
|
||||
3. Check for regressions: did any fix break something else?
|
||||
4. Check for consistency: do all the changes work together?
|
||||
|
||||
Respond with JSON (not by writing out a file):
|
||||
{
|
||||
\"model\": \"codex\",
|
||||
\"total_changes_reviewed\": N,
|
||||
\"all_correct\": true/false,
|
||||
\"issues_found\": [ {\"file\": \"...\", \"issue\": \"...\", \"severity\": \"critical|minor\"} ],
|
||||
\"remaining_implementable\": M
|
||||
}
|
||||
|
||||
If issues_found contains any critical items, set preferred_next_label to \"More fixes needed\".
|
||||
If remaining_implementable > 0 and no critical issues, set preferred_next_label to \"More fixes needed\".
|
||||
Otherwise set preferred_next_label to \"Ready for build\"."
|
||||
]
|
||||
|
||||
/*========================================================================
|
||||
* PHASE 6 — Build Verification
|
||||
*======================================================================*/
|
||||
|
||||
build_check [
|
||||
label="Build & Smoke Test",
|
||||
shape=parallelogram,
|
||||
script="cd /Users/bhelmkamp/p/brynary/attractor-rust && cargo build 2>&1 && echo '---BUILD OK---' && ./target/debug/attractor run --dry-run test/simple.dot 2>&1 && ./target/debug/attractor run --dry-run test/branching.dot 2>&1 && ./target/debug/attractor run --dry-run test/styled.dot 2>&1 && ./target/debug/attractor run --dry-run test/parallel.dot 2>&1 && ./target/debug/attractor run --dry-run test/conditions.dot 2>&1 && echo '---ALL TESTS PASSED---'",
|
||||
timeout="120s"
|
||||
]
|
||||
|
||||
build_fix [
|
||||
label="Opus: Fix Build Errors",
|
||||
shape=box,
|
||||
class="opus",
|
||||
fidelity="full",
|
||||
prompt="The build or smoke tests failed. The build output is in context key command.output. Diagnose the compilation errors or test failures and fix them.
|
||||
|
||||
Read the relevant source files, identify the issue, and write corrected versions. Common issues:
|
||||
- Missing includes
|
||||
- Type mismatches
|
||||
- Undeclared functions
|
||||
|
||||
Output the fixes applied and ensure the code will compile cleanly with: cargo build"
|
||||
]
|
||||
|
||||
/*========================================================================
|
||||
* PHASE 7 — Dual Final Audit (interleaved, fidelity-isolated)
|
||||
*
|
||||
* Both models independently verify the fixes worked.
|
||||
* If either model finds a remaining failure, it counts.
|
||||
*======================================================================*/
|
||||
|
||||
final_audit_opus [
|
||||
label="Opus: Final Verification",
|
||||
shape=box,
|
||||
class="opus",
|
||||
fidelity="full",
|
||||
prompt="This is a verification pass. The items that were previously failing are listed in context key response.triage_merge (the implementable list). The fixes applied are in response.fix_codex and response.review_fix_opus.
|
||||
|
||||
Re-read all three spec DoD sections:
|
||||
- docs/specs/unified-llm-spec.md Section 8
|
||||
- docs/specs/coding-agent-loop-spec.md Section 9
|
||||
- docs/specs/attractor-spec.md Section 11
|
||||
|
||||
And re-read the implementation files that were changed in this iteration.
|
||||
|
||||
Check ONLY the items that were previously failing. Have they been fixed?
|
||||
|
||||
Respond with JSON (not by writing out a file):
|
||||
{
|
||||
\"model\": \"opus\",
|
||||
\"verified_fixed\": [ {\"spec\": \"...\", \"section\": \"...\", \"text\": \"...\"} ],
|
||||
\"still_failing\": [ {\"spec\": \"...\", \"section\": \"...\", \"text\": \"...\", \"reason\": \"...\"} ],
|
||||
\"newly_broken\": [ ... ],
|
||||
\"remaining_total\": N
|
||||
}"
|
||||
]
|
||||
|
||||
final_audit_gpt [
|
||||
label="GPT-5.2: Final Verification",
|
||||
shape=box,
|
||||
class="gpt",
|
||||
fidelity="full",
|
||||
prompt="This is a verification pass. The items that were previously failing are listed in context key response.triage_merge (the implementable list). The fixes applied are in response.fix_codex and response.review_fix_opus.
|
||||
|
||||
Re-read all three spec DoD sections:
|
||||
- docs/specs/unified-llm-spec.md Section 8
|
||||
- docs/specs/coding-agent-loop-spec.md Section 9
|
||||
- docs/specs/attractor-spec.md Section 11
|
||||
|
||||
And re-read the implementation files that were changed in this iteration.
|
||||
|
||||
Check ONLY the items that were previously failing. Have they been fixed?
|
||||
|
||||
Respond with JSON (not by writing out a file):
|
||||
{
|
||||
\"model\": \"gpt-5.2\",
|
||||
\"verified_fixed\": [ {\"spec\": \"...\", \"section\": \"...\", \"text\": \"...\"} ],
|
||||
\"still_failing\": [ {\"spec\": \"...\", \"section\": \"...\", \"text\": \"...\", \"reason\": \"...\"} ],
|
||||
\"newly_broken\": [ ... ],
|
||||
\"remaining_total\": N
|
||||
}"
|
||||
]
|
||||
|
||||
final_consensus [
|
||||
label="Merge: Final Consensus",
|
||||
shape=box,
|
||||
class="merge",
|
||||
fidelity="full",
|
||||
prompt="You have final audit results from both models in context: response.final_audit_opus and response.final_audit_gpt. Merge them into a definitive status.
|
||||
|
||||
Rules:
|
||||
1. An item is only \"verified_fixed\" if BOTH models agree it's fixed
|
||||
2. If EITHER model says an item is still failing, it counts as still failing
|
||||
3. Union all newly_broken items from both models
|
||||
|
||||
Respond with JSON (not by writing out a file):
|
||||
{
|
||||
\"verified_fixed\": [ {\"spec\": \"...\", \"section\": \"...\", \"text\": \"...\", \"agreed_by\": \"both|opus_only|gpt_only\"} ],
|
||||
\"still_failing\": [ {\"spec\": \"...\", \"section\": \"...\", \"text\": \"...\", \"flagged_by\": \"both|opus_only|gpt_only\", \"reason\": \"...\"} ],
|
||||
\"newly_broken\": [ ... ],
|
||||
\"remaining_total\": N
|
||||
}
|
||||
|
||||
If remaining_total == 0 (ignoring DEFERRED items), set preferred_next_label to \"Complete\".
|
||||
Otherwise set preferred_next_label to \"More work needed\"."
|
||||
]
|
||||
|
||||
/*========================================================================
|
||||
* PHASE 8 — Human Gate
|
||||
*======================================================================*/
|
||||
|
||||
review_gate [
|
||||
label="A) Accept & finish\nB) Push for another round",
|
||||
shape=hexagon
|
||||
]
|
||||
|
||||
/*========================================================================
|
||||
* EDGES — Serial interleaved chain
|
||||
*
|
||||
* The engine is single-path, so we interleave model audits per-spec.
|
||||
* fidelity="truncate" on audit nodes prevents cross-model anchoring.
|
||||
*======================================================================*/
|
||||
|
||||
/* Phase 1: Interleaved audits (Opus then GPT for each spec) */
|
||||
start -> audit_llm_opus
|
||||
audit_llm_opus -> audit_llm_gpt
|
||||
audit_llm_gpt -> audit_agent_opus
|
||||
audit_agent_opus -> audit_agent_gpt
|
||||
audit_agent_gpt -> audit_attractor_opus
|
||||
audit_attractor_opus -> audit_attractor_gpt
|
||||
|
||||
/* Phase 2: Cross-critique (now sequential — GPT critiques Opus, then Opus critiques GPT) */
|
||||
audit_attractor_gpt -> critique_by_gpt
|
||||
critique_by_gpt -> critique_by_opus
|
||||
|
||||
/* Phase 3: Consensus */
|
||||
critique_by_opus -> audit_consensus
|
||||
|
||||
/* Phase 4: Dual triage (sequential — Opus then GPT then merge) */
|
||||
audit_consensus -> triage_opus
|
||||
triage_opus -> triage_gpt
|
||||
triage_gpt -> triage_merge
|
||||
|
||||
/* Triage decision */
|
||||
triage_merge -> exit [label="Done", condition="preferred_label=Done"]
|
||||
triage_merge -> fix_codex [label="Fix", condition="preferred_label=Fix", weight=10]
|
||||
triage_merge -> exit [label="Only deferred remain"]
|
||||
|
||||
/* Phase 5: Multi-model implementation (sequential alternation) */
|
||||
fix_codex -> review_fix_opus
|
||||
review_fix_opus -> review_codex
|
||||
|
||||
/* Implementation loop */
|
||||
review_codex -> fix_codex [label="More fixes needed", condition="preferred_label=More fixes needed", loop_restart=true]
|
||||
review_codex -> build_check [label="Ready for build", condition="preferred_label=Ready for build"]
|
||||
|
||||
/* Phase 6: Build */
|
||||
build_check -> final_audit_opus [label="Build OK", condition="outcome=success"]
|
||||
build_check -> build_fix [label="Build failed", condition="outcome=fail"]
|
||||
build_fix -> build_check
|
||||
|
||||
/* Phase 7: Dual final audit (sequential — Opus then GPT then consensus) */
|
||||
final_audit_opus -> final_audit_gpt
|
||||
final_audit_gpt -> final_consensus
|
||||
|
||||
/* Final decision */
|
||||
final_consensus -> review_gate [label="Complete", condition="preferred_label=Complete"]
|
||||
final_consensus -> triage_merge [label="More work needed", condition="preferred_label=More work needed"]
|
||||
|
||||
/* Phase 8: Human gate */
|
||||
review_gate -> exit [label="A) Accept"]
|
||||
review_gate -> triage_merge [label="B) Another round"]
|
||||
}
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 151 KiB |
|
|
@ -1,254 +0,0 @@
|
|||
digraph SpecDoD {
|
||||
graph [
|
||||
goal="Satisfy every Definition of Done checkbox across all three attractor specs (unified-llm-spec.md, coding-agent-loop-spec.md, attractor-spec.md). The implementation is in Rust under crates/. Do NOT modify the spec files. Only modify implementation code.",
|
||||
default_max_retry="3",
|
||||
retry_target="triage",
|
||||
model_stylesheet="
|
||||
* { model: claude-opus-4-6;}
|
||||
.audit { reasoning_effort: high; }
|
||||
.fix { model: claude-opus-4-6; reasoning_effort: high; }
|
||||
#final_audit { reasoning_effort: high; }
|
||||
"
|
||||
]
|
||||
|
||||
start [shape=Mdiamond]
|
||||
exit [shape=Msquare]
|
||||
|
||||
/*------------------------------------------------------------------------
|
||||
* Phase 1: Baseline audit — read every DoD checkbox, check the code
|
||||
*----------------------------------------------------------------------*/
|
||||
|
||||
audit_llm [
|
||||
label="Audit: Unified LLM Client DoD",
|
||||
shape=box,
|
||||
class="audit",
|
||||
prompt="Read docs/specs/unified-llm-spec.md Section 8 (Definition of Done) in full. Then read every source file under crates/llm/src/.
|
||||
|
||||
For EACH checkbox in sections 8.1 through 8.10, evaluate whether the current Rust implementation satisfies it. Be strict — a checkbox is only checked if the feature is fully implemented and would work correctly at runtime.
|
||||
|
||||
Respond with ONLY a JSON object (no prose) -- don't write it out as a file:
|
||||
{
|
||||
\"spec\": \"unified-llm\",
|
||||
\"sections\": {
|
||||
\"8.1\": { \"title\": \"Core Infrastructure\", \"items\": [ {\"text\": \"...\", \"pass\": true/false, \"reason\": \"...\"} ] },
|
||||
...
|
||||
},
|
||||
\"total\": N,
|
||||
\"passed\": M,
|
||||
\"failed\": K,
|
||||
\"failed_items\": [ {\"section\": \"8.2\", \"text\": \"...\", \"reason\": \"...\"} ]
|
||||
}
|
||||
|
||||
Be thorough. Check every single checkbox."
|
||||
]
|
||||
|
||||
audit_agent [
|
||||
label="Audit: Coding Agent Loop DoD",
|
||||
shape=box,
|
||||
class="audit",
|
||||
prompt="Read docs/specs/coding-agent-loop-spec.md Section 9 (Definition of Done) in full. Then read every source file under crates/agent/.
|
||||
|
||||
For EACH checkbox in sections 9.1 through 9.13, evaluate whether the current Rust implementation satisfies it. Be strict.
|
||||
|
||||
Respond with ONLY a JSON object (no prose) -- don't write it out as a file:
|
||||
{
|
||||
\"spec\": \"coding-agent-loop\",
|
||||
\"sections\": { ... },
|
||||
\"total\": N,
|
||||
\"passed\": M,
|
||||
\"failed\": K,
|
||||
\"failed_items\": [ {\"section\": \"9.1\", \"text\": \"...\", \"reason\": \"...\"} ]
|
||||
}
|
||||
|
||||
Be thorough. Check every single checkbox."
|
||||
]
|
||||
|
||||
audit_attractor [
|
||||
label="Audit: Attractor Pipeline DoD",
|
||||
shape=box,
|
||||
class="audit",
|
||||
prompt="Read docs/specs/attractor-spec.md Section 11 (Definition of Done) in full. Then read every source file under crates/attractor/.
|
||||
|
||||
For EACH checkbox in sections 11.1 through 11.13, evaluate whether the current Rust implementation satisfies it. Be strict.
|
||||
|
||||
Respond with ONLY a JSON object (no prose) -- don't write it out as a file:
|
||||
{
|
||||
\"spec\": \"attractor\",
|
||||
\"sections\": { ... },
|
||||
\"total\": N,
|
||||
\"passed\": M,
|
||||
\"failed\": K,
|
||||
\"failed_items\": [ {\"section\": \"11.1\", \"text\": \"...\", \"reason\": \"...\"} ]
|
||||
}
|
||||
|
||||
Be thorough. Check every single checkbox."
|
||||
]
|
||||
|
||||
/*------------------------------------------------------------------------
|
||||
* Phase 2: Triage — merge results, prioritize failures, decide next step
|
||||
*----------------------------------------------------------------------*/
|
||||
|
||||
triage [
|
||||
label="Triage & Prioritize",
|
||||
shape=box,
|
||||
prompt="You have three audit reports in context (from audit_llm, audit_agent, audit_attractor). Merge them into a single prioritized list of ALL failing DoD checkboxes.
|
||||
|
||||
Group failures into:
|
||||
1. IMPLEMENTABLE — can be fixed by writing/modifying Rust code (functions, handlers, logic)
|
||||
2. STRUCTURAL — requires new files, new modules, or significant architecture changes
|
||||
3. DEFERRED — requires external resources (real API keys, network access, interactive testing) that cannot be done in a code-only pass
|
||||
|
||||
For each IMPLEMENTABLE item, identify the exact file(s) to modify and briefly describe the fix.
|
||||
|
||||
Respond with JSON (not by writing out a file):
|
||||
{
|
||||
\"total_failing\": N,
|
||||
\"implementable\": [ {\"spec\": \"...\", \"section\": \"...\", \"text\": \"...\", \"files\": [\"...\"], \"fix\": \"...\"} ],
|
||||
\"structural\": [ ... ],
|
||||
\"deferred\": [ ... ],
|
||||
\"verdict\": \"all_clear\" | \"has_fixes\" | \"only_deferred\"
|
||||
}
|
||||
|
||||
If total_failing == 0 or verdict == \"only_deferred\", set preferred_next_label to \"Done\".
|
||||
Otherwise set preferred_next_label to \"Fix\"."
|
||||
]
|
||||
|
||||
/*------------------------------------------------------------------------
|
||||
* Phase 3: Fix — implement the highest-priority fixes
|
||||
*----------------------------------------------------------------------*/
|
||||
|
||||
fix_batch [
|
||||
label="Implement Fixes",
|
||||
shape=box,
|
||||
class="fix",
|
||||
goal_gate=true,
|
||||
prompt="The triage report identified IMPLEMENTABLE DoD failures. Pick the top 5 most impactful items (or all if fewer than 5) and implement the fixes in Rust.
|
||||
|
||||
Begin by making sure the build is green with `cargo test`
|
||||
|
||||
For each fix:
|
||||
1. Read the relevant source file(s)
|
||||
2. Make the minimal change needed to satisfy the DoD checkbox
|
||||
3. Write the modified file(s) -- update tests as needed
|
||||
4. Verify the fix and the tests pass (`cargo test`)
|
||||
|
||||
Constraints:
|
||||
- Do NOT modify any files under docs/specs/ (those are the specs)
|
||||
- Do NOT add external dependencies beyond what's already used
|
||||
- Keep changes minimal and focused — one checkbox per fix
|
||||
- Maintain the existing code style
|
||||
|
||||
Respond with JSON (not by writing out a file):
|
||||
{
|
||||
\"fixes_applied\": [ {\"spec\": \"...\", \"section\": \"...\", \"text\": \"...\", \"files_changed\": [\"...\"], \"description\": \"...\"} ],
|
||||
\"count\": N,
|
||||
\"remaining_implementable\": M
|
||||
}
|
||||
|
||||
If remaining_implementable > 0, set preferred_next_label to \"More fixes needed\".
|
||||
Otherwise set preferred_next_label to \"Re-audit\"."
|
||||
]
|
||||
|
||||
/*------------------------------------------------------------------------
|
||||
* Phase 4: Build verification
|
||||
*----------------------------------------------------------------------*/
|
||||
|
||||
build_check [
|
||||
label="Build & Smoke Test",
|
||||
shape=parallelogram,
|
||||
script="cd /Users/bhelmkamp/p/brynary/attractor-rust && cargo build 2>&1 && echo '---BUILD OK---' && ./target/debug/attractor run --dry-run test/simple.dot 2>&1 && ./target/debug/attractor run --dry-run test/branching.dot 2>&1 && ./target/debug/attractor run --dry-run test/styled.dot 2>&1 && ./target/debug/attractor run --dry-run test/parallel.dot 2>&1 && ./target/debug/attractor run --dry-run test/conditions.dot 2>&1 && echo '---ALL TESTS PASSED---'",
|
||||
timeout="120s"
|
||||
]
|
||||
|
||||
/*------------------------------------------------------------------------
|
||||
* Phase 5: Build failure recovery
|
||||
*----------------------------------------------------------------------*/
|
||||
|
||||
build_fix [
|
||||
label="Fix Build Errors",
|
||||
shape=box,
|
||||
class="fix",
|
||||
prompt="The build or smoke tests failed. Read the build output from context (command.output key). Diagnose the compilation errors or test failures and fix them.
|
||||
|
||||
Read the relevant source files, identify the issue, and write corrected versions. Common issues:
|
||||
- Missing includes
|
||||
- Type mismatches
|
||||
- Undeclared functions
|
||||
|
||||
Output the fixes applied and ensure the code will compile cleanly with: cargo build"
|
||||
]
|
||||
|
||||
/*------------------------------------------------------------------------
|
||||
* Phase 6: Final audit to confirm fixes worked
|
||||
*----------------------------------------------------------------------*/
|
||||
|
||||
final_audit [
|
||||
label="Final Verification Audit",
|
||||
shape=box,
|
||||
prompt="This is a verification pass. Re-read all three spec DoD sections:
|
||||
- docs/specs/unified-llm-spec.md Section 8
|
||||
- docs/specs/coding-agent-loop-spec.md Section 9
|
||||
- docs/specs/attractor-spec.md Section 11
|
||||
|
||||
And re-read the implementation files that were changed in this iteration.
|
||||
|
||||
Check ONLY the items that were previously failing. Have they been fixed?
|
||||
|
||||
Respond with JSON (not by writing out a file):
|
||||
{
|
||||
\"verified_fixed\": [ {\"spec\": \"...\", \"section\": \"...\", \"text\": \"...\"} ],
|
||||
\"still_failing\": [ {\"spec\": \"...\", \"section\": \"...\", \"text\": \"...\", \"reason\": \"...\"} ],
|
||||
\"newly_broken\": [ ... ],
|
||||
\"remaining_total\": N
|
||||
}
|
||||
|
||||
If remaining_total == 0 (ignoring DEFERRED items), set preferred_next_label to \"Complete\".
|
||||
Otherwise set preferred_next_label to \"More work needed\"."
|
||||
]
|
||||
|
||||
/*------------------------------------------------------------------------
|
||||
* Phase 7: Human gate — confirm completion or push for another round
|
||||
*----------------------------------------------------------------------*/
|
||||
|
||||
review_gate [
|
||||
label="A) Accept & finish\nB) Push for another round",
|
||||
shape=hexagon
|
||||
]
|
||||
|
||||
/*------------------------------------------------------------------------
|
||||
* Edges
|
||||
*----------------------------------------------------------------------*/
|
||||
|
||||
start -> audit_llm
|
||||
|
||||
/* Sequential audit chain */
|
||||
audit_llm -> audit_agent
|
||||
audit_agent -> audit_attractor
|
||||
audit_attractor -> triage
|
||||
|
||||
/* Triage decision */
|
||||
triage -> exit [label="Done", condition="preferred_label=Done"]
|
||||
triage -> fix_batch [label="Fix", condition="preferred_label=Fix", weight=10]
|
||||
triage -> exit [label="Only deferred remain"]
|
||||
|
||||
/* Fix -> build check */
|
||||
fix_batch -> build_check
|
||||
|
||||
/* Build check outcomes */
|
||||
build_check -> final_audit [label="Build OK", condition="outcome=success"]
|
||||
build_check -> build_fix [label="Build failed", condition="outcome=fail"]
|
||||
|
||||
/* Build fix loops back to build check */
|
||||
build_fix -> build_check
|
||||
|
||||
/* Fix batch can loop for more fixes */
|
||||
fix_batch -> fix_batch [label="More fixes needed", condition="preferred_label=More fixes needed", loop_restart=true]
|
||||
|
||||
/* Final audit outcomes */
|
||||
final_audit -> review_gate [label="Complete", condition="preferred_label=Complete"]
|
||||
final_audit -> triage [label="More work needed", condition="preferred_label=More work needed"]
|
||||
|
||||
/* Human review gate */
|
||||
review_gate -> exit [label="A) Accept"]
|
||||
review_gate -> triage [label="B) Another round"]
|
||||
}
|
||||
|
|
@ -1,27 +0,0 @@
|
|||
FROM node:22-bookworm-slim
|
||||
|
||||
RUN apt-get update && apt-get install -y --no-install-recommends \
|
||||
# VNC & desktop
|
||||
xvfb \
|
||||
xfce4 \
|
||||
xfce4-terminal \
|
||||
x11vnc \
|
||||
novnc \
|
||||
dbus-x11 \
|
||||
# X11 libraries
|
||||
libx11-6 \
|
||||
libxrandr2 \
|
||||
libxext6 \
|
||||
libxrender1 \
|
||||
libxfixes3 \
|
||||
libxss1 \
|
||||
libxtst6 \
|
||||
libxi6 \
|
||||
# Utilities
|
||||
curl \
|
||||
git \
|
||||
ca-certificates \
|
||||
procps \
|
||||
&& rm -rf /var/lib/apt/lists/*
|
||||
|
||||
WORKDIR /root
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
You have Playwright MCP tools available running in headed mode — a user is watching via VNC.
|
||||
|
||||
1. Call the `browser_install` tool to ensure the browser is installed.
|
||||
2. Use `browser_navigate` to go to https://news.ycombinator.com
|
||||
3. Use `browser_snapshot` to capture the page content
|
||||
4. Use `browser_take_screenshot` to save a screenshot to `/root/output/01-hn-front-page.png`
|
||||
5. Click on the first story link
|
||||
6. Wait a moment, then use `browser_take_screenshot` to save to `/root/output/02-first-story.png`
|
||||
7. Use `browser_navigate_back` to go back
|
||||
8. Click on the "new" link in the nav bar
|
||||
9. Use `browser_take_screenshot` to save to `/root/output/03-newest.png`
|
||||
10. Navigate to https://en.wikipedia.org/wiki/Golden_Gate_Bridge
|
||||
11. Use `browser_take_screenshot` to save to `/root/output/04-golden-gate.png`
|
||||
12. Scroll down to see images, then take another screenshot to `/root/output/05-golden-gate-scrolled.png`
|
||||
|
||||
Take your time between actions so the VNC viewer can see what's happening. Write a brief summary of what you found.
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
digraph VNCDemo {
|
||||
graph [
|
||||
goal="Browse the web with Playwright while user watches via VNC",
|
||||
model_stylesheet="* { model: claude-sonnet-4-6;}"
|
||||
]
|
||||
rankdir=LR
|
||||
|
||||
start [shape=Mdiamond, label="Start"]
|
||||
exit [shape=Msquare, label="Exit"]
|
||||
|
||||
start_vnc [label="Start VNC", shape=parallelogram, script="setsid sh -c 'Xvfb :99 -screen 0 1920x1080x24 &\nsleep 1\nexport DISPLAY=:99\nstartxfce4 &\nsleep 1\nx11vnc -display :99 -forever -nopw -rfbport 5900' </dev/null >/dev/null 2>&1 &\nsleep 3\nmkdir -p /root/output\necho 'VNC ready on display :99'"]
|
||||
|
||||
browse [label="Browse the Web", prompt="@browse-prompt.md"]
|
||||
|
||||
start -> start_vnc -> browse -> exit
|
||||
}
|
||||
|
|
@ -1,33 +0,0 @@
|
|||
version = 1
|
||||
goal = "Browse the web with Playwright while user watches via VNC"
|
||||
graph = "workflow.fabro"
|
||||
|
||||
[llm]
|
||||
model = "claude-sonnet-4-6"
|
||||
|
||||
[sandbox]
|
||||
provider = "daytona"
|
||||
|
||||
[sandbox.daytona]
|
||||
auto_stop_interval = 30
|
||||
|
||||
[sandbox.daytona.labels]
|
||||
project = "vnc-demo"
|
||||
|
||||
[sandbox.daytona.snapshot]
|
||||
name = "vnc-demo-v1"
|
||||
cpu = 4
|
||||
memory = 8
|
||||
disk = 10
|
||||
dockerfile = { path = "Dockerfile.vnc" }
|
||||
|
||||
[assets]
|
||||
include = ["output/**"]
|
||||
|
||||
[mcp_servers.playwright]
|
||||
type = "sandbox"
|
||||
command = ["npx", "@playwright/mcp@latest", "--port", "3100", "--no-headless", "--browser", "chromium"]
|
||||
port = 3100
|
||||
startup_timeout_secs = 60
|
||||
tool_timeout_secs = 120
|
||||
env = { DISPLAY = ":99" }
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
Your task is to verify that the develop-web-game skill is properly set up.
|
||||
|
||||
1. Call the `browser_install` Playwright MCP tool to ensure the browser is installed.
|
||||
2. Call the `use_skill` tool with skill_name "develop-web-game" to load the skill instructions.
|
||||
3. Read the skill instructions and identify the asset file paths referenced in them.
|
||||
4. Verify the following files exist and are readable:
|
||||
- `skills/develop-web-game/scripts/web_game_playwright_client.js`
|
||||
- `skills/develop-web-game/references/action_payloads.json`
|
||||
- `skills/develop-web-game/SKILL.md`
|
||||
5. Read the contents of `action_payloads.json` and confirm it contains valid JSON with a "steps" array.
|
||||
6. Read the first 10 lines of `web_game_playwright_client.js` and confirm it imports playwright.
|
||||
7. Write a summary report to `output/skill-verification.md` with the results.
|
||||
|
||||
Report success or failure for each check.
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
digraph WebGameDemo {
|
||||
graph [
|
||||
goal="Verify develop-web-game skill setup with asset files",
|
||||
model_stylesheet="* { model: claude-sonnet-4-6;}"
|
||||
]
|
||||
rankdir=LR
|
||||
|
||||
start [shape=Mdiamond, label="Start"]
|
||||
exit [shape=Msquare, label="Exit"]
|
||||
|
||||
verify_skill [label="Verify Skill Setup", prompt="@verify-prompt.md"]
|
||||
|
||||
start -> verify_skill -> exit
|
||||
}
|
||||
|
|
@ -1,28 +0,0 @@
|
|||
version = 1
|
||||
goal = "Verify the develop-web-game skill is properly set up with its asset files"
|
||||
graph = "workflow.fabro"
|
||||
|
||||
[llm]
|
||||
model = "claude-sonnet-4-6"
|
||||
|
||||
[sandbox]
|
||||
provider = "daytona"
|
||||
|
||||
[sandbox.daytona]
|
||||
auto_stop_interval = 30
|
||||
|
||||
[sandbox.daytona.labels]
|
||||
project = "web-game-demo"
|
||||
|
||||
[sandbox.daytona.snapshot]
|
||||
name = "daytona-medium"
|
||||
|
||||
[assets]
|
||||
include = ["output/**"]
|
||||
|
||||
[mcp_servers.playwright]
|
||||
type = "sandbox"
|
||||
command = ["npx", "@playwright/mcp@latest", "--port", "3100", "--headless", "--browser", "chromium"]
|
||||
port = 3100
|
||||
startup_timeout_secs = 60
|
||||
tool_timeout_secs = 120
|
||||
Loading…
Add table
Reference in a new issue