Skip to content

Remove AI agent documents #118

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
marpaia wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Remove AI agent documents #118

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions ADR-001.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -20,7 +20,7 @@ The current BuildCompiler prototype proves important pieces of the desired workf
- manual protocol helpers
- Opentrons simulation helpers

The new `full_build` vision requires a dependency-resolving compiler pipeline, partial success semantics, route optimization, structured blockers, approvals, graph/reporting, and optional protocol generation. Preserving old APIs and module boundaries would slow implementation and make Codex work harder to verify.
The new `full_build` vision requires a dependency-resolving compiler pipeline, partial success semantics, route optimization, structured blockers, approvals, graph/reporting, and optional protocol generation. Preserving old APIs and module boundaries would slow implementation and make changes harder to verify.

## Decision

Expand Down Expand Up @@ -73,7 +73,7 @@ Cons:

- Reinforces the current god-class structure.
- Makes partial success and structured blockers awkward.
- Makes Codex tasks harder to scope.
- Makes changes harder to scope.
- Encourages hidden compatibility behavior.
- Risks coupling PUDU/Opentrons side effects to compiler-only mode.

Expand All @@ -96,7 +96,7 @@ Cons:
Pros:

- Best long-term module boundaries.
- Makes Codex tasks smaller and safer.
- Supports smaller, safer changes.
- Enables testable contracts before complex stages.
- Separates compiler-only mode from automation side effects.
- Treats expected build blockers as structured data.
Expand Down Expand Up @@ -137,7 +137,7 @@ Those concerns need explicit boundaries.
- Stages use a uniform `run(request, context) -> StageResult` contract.
- Inventory records replace the old `Plasmid` class.
- PUDU/Opentrons are optional adapters, not core dependencies.
- Codex should implement in milestone order and keep tests passing at each step.
- Implementation should proceed in milestone order with tests passing at each step.

## Risks and mitigations

Expand Down
Loading
Loading