diff --git a/ADR-001.md b/ADR-001.md index 076a6ff..21edfb5 100644 --- a/ADR-001.md +++ b/ADR-001.md @@ -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 @@ -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. @@ -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. @@ -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 diff --git a/AGENT.md b/AGENT.md deleted file mode 100644 index bda13fb..0000000 --- a/AGENT.md +++ /dev/null @@ -1,402 +0,0 @@ -# Agent Guide for BuildCompiler - -## Mission - -Codex should implement the BuildCompiler clean-architecture refactor in small, verifiable increments. The goal is not to preserve legacy APIs. The current repository is inspiration and evidence, especially for level-1 assembly and SBOL digestion/ligation behavior. - -## Role split - -### ChatGPT owns - -- Reducing ambiguity. -- Revising architecture and product decisions. -- Breaking work into milestones and tasks. -- Deciding between alternatives when requirements conflict. -- Reviewing whether Codex output matches the intended plan. -- Updating this guidance when product or architecture decisions change. - -### Codex owns - -- Creating and editing repository files. -- Implementing scoped tasks. -- Refactoring within approved boundaries. -- Adding tests. -- Running checks. -- Reporting assumptions, blockers, and deviations. - -When a decision changes architecture, product scope, biological behavior, or public API semantics, Codex should stop and ask ChatGPT/user for a decision before continuing. - -## Hard rules - -1. Prefer small, incremental changes. -2. Keep the project runnable after every task. -3. Write tests for non-trivial logic. -4. Update docs when architecture, behavior, or commands change. -5. Do not preserve legacy APIs unless explicitly requested. -6. Do not add compatibility wrappers. -7. Do not silently expand scope. -8. Do not hide assumptions. -9. Do not make PUDU or Opentrons required for core tests. -10. Do not run Opentrons simulation by default. -11. Do not silently mutate biological sequences. -12. Do not silently assume reagent purchase. -13. Keep domain contracts identity-based where possible. -14. Keep raw `sbol2` objects at inventory/SBOL/stage boundaries. -15. Use `SbolResolver` instead of scattered direct SBOL document lookup. -16. Use structured blockers, warnings, and approvals instead of raw exceptions for expected build issues. -17. Raise unexpected implementation errors by default. - -## Definition of a safe Codex task - -A task is safe for Codex when it has: - -- A clear target file or module. -- A clear expected behavior. -- A test strategy. -- No unresolved product or architecture tradeoff. -- No need to choose between incompatible biological semantics. - -Examples: - -- Add `StageStatus`, `BuildStatus`, and tests. -- Implement `BuildOptions` dataclasses. -- Create `SbolResolver` with `PullPolicy.NEVER` unit tests. -- Add `Inventory.add_generated_product()` and indexing tests. -- Port `Assembly` behind `AssemblyService` without changing internals. - -## Definition of a risky task - -A task is risky when it: - -- Changes public API semantics. -- Changes build-stage behavior. -- Changes approval or sequence-edit policy. -- Changes route-selection ranking. -- Changes material-state semantics. -- Touches PUDU/Opentrons execution side effects. -- Requires choosing how SBOL structures should be interpreted. -- Would take more than one focused PR. - -Risky tasks should be decomposed or escalated to ChatGPT/user. - -## Handoff protocol - -Every Codex task should begin with: - -```text -Task goal: -Files expected to change: -Behavior expected: -Tests expected: -Known constraints: -``` - -Every Codex completion should report: - -```text -Implemented: -Tests added/updated: -Commands run: -Assumptions made: -Blockers or follow-up tasks: -``` - -If tests cannot be run, Codex must say why and identify the smallest command that should be run later. - -## Implementation sequence - -Implement in milestone order. Do not jump directly to the full-build loop before contracts and tests exist. - -### Milestone 1: Domain contracts and options - -Create: - -```text -src/buildcompiler/domain/ -src/buildcompiler/api/options.py -``` - -Add contracts for: - -- `BuildStage` -- `StageStatus` -- `BuildStatus` -- `MaterialState` -- `BuildRequest` -- `StageResult` -- `FullBuildResult` -- `MissingBuildInput` -- `RequiredApproval` -- `BuildWarning` -- `IndexedPlasmid` -- `IndexedBackbone` -- `IndexedReagent` -- `BuildOptions` and focused option groups - -Tests: - -```text -tests/unit/domain/ -tests/unit/api/test_options.py -``` - -### Milestone 2: SBOL resolver and inventory - -Create: - -```text -src/buildcompiler/sbol/resolver.py -src/buildcompiler/inventory/ -``` - -Implement: - -- `PullPolicy` -- `SbolResolver` -- normalized inventory records -- eager indexes -- generated-product indexing -- reagent lookup -- backbone lookup - -Tests should use offline SBOL fixtures and `PullPolicy.NEVER`. - -### Milestone 3: Planner and classification - -Create: - -```text -src/buildcompiler/planning/classifier.py -src/buildcompiler/planning/combinatorial.py -src/buildcompiler/planning/full_build_planner.py -src/buildcompiler/planning/validation.py -``` - -Implement classification rules: - -```text -ModuleDefinition -> assembly_lvl2 -CombinatorialDerivation -> expanded assembly_lvl1 requests -ComponentDefinition >1 component -> assembly_lvl1 -ComponentDefinition <=1 component with supported role -> domestication -ComponentDefinition <=1 component unsupported -> unsupported -``` - -Implement combinatorial cap and invalid variant warnings. - -### Milestone 4: Compatibility selector and route models - -Create: - -```text -src/buildcompiler/inventory/selector.py -src/buildcompiler/inventory/compatibility.py -``` - -Implement route scoring dataclasses for level-1 and level-2. Keep scores explicit, not opaque numbers. - -### Milestone 5: SBOL assembly service and level-1 stage - -Port current working `Assembly` behavior into: - -```text -src/buildcompiler/sbol/assembly.py -``` - -Wrap it with: - -```text -src/buildcompiler/stages/assembly_lvl1.py -``` - -Do not deeply refactor SBOL internals until tests protect the new service interface. - -### Milestone 6: Domestication stage - -Create: - -```text -src/buildcompiler/sbol/domestication.py -src/buildcompiler/stages/domestication.py -``` - -Implement: - -- supported role validation -- missing backbone handling -- missing reagent handling -- sequence edit proposals -- approval-gated execution behavior -- domesticated plasmid output - -### Milestone 7: Level-2 stage - -Create: - -```text -src/buildcompiler/stages/assembly_lvl2.py -``` - -Implement: - -- `ModuleDefinition` engineered-region extraction -- optional `region_order` constraint -- exhaustive order search up to 4 regions -- missing level-1 promotion -- selected route and top rejected alternatives - -### Milestone 8: Full-build executor - -Create: - -```text -src/buildcompiler/execution/full_build_executor.py -src/buildcompiler/execution/worklist.py -src/buildcompiler/execution/stage_runner.py -src/buildcompiler/execution/context.py -``` - -Implement bounded retry loop with mocked/stubbed stages first, then wire real stages. - -### Milestone 9: Transformation and plating - -Create: - -```text -src/buildcompiler/stages/transformation.py -src/buildcompiler/stages/plating.py -src/buildcompiler/sbol/transformation.py -``` - -Implement SBOL transformation records, PUDU JSON intermediates, plate mapping, and deduplication. - -### Milestone 10: Adapters, reporting, and integration tests - -Create: - -```text -src/buildcompiler/adapters/pudu/ -src/buildcompiler/adapters/opentrons/ -src/buildcompiler/reporting/ -``` - -Implement: - -- assembly/transformation/plating JSON adapters -- optional manual/automated protocol file generation -- optional Opentrons simulation wrapper -- `BuildSummary` -- opt-in `BuildReport` -- reporting-only `BuildGraph` -- end-to-end happy-path fixture test - -## Testing and verification expectations - -Use pytest and Ruff for default CI. - -Core commands: - -```bash -uv run ruff check . -uv run ruff format --check . -uv run pytest -``` - -Fallback without `uv`: - -```bash -ruff check . -ruff format --check . -pytest -``` - -Automation-specific tests should be marked and optional: - -```bash -pytest -m automation -``` - -Suggested test layout: - -```text -tests/ - unit/ - domain/ - planning/ - inventory/ - execution/ - reporting/ - stages/ - test_assembly_lvl1.py - test_domestication.py - test_assembly_lvl2.py - test_transformation.py - test_plating.py - integration/ - test_full_build_happy_path.py - test_full_build_missing_lvl1_then_domestication.py - automation/ - test_pudu_json_adapters.py - test_opentrons_simulation_smoke.py - fixtures/ - sbol/ - expected_json/ -``` - -## Documentation update rules - -Update docs in the same PR when: - -- public API changes -- package layout changes -- option defaults change -- stage behavior changes -- status semantics change -- approval behavior changes -- route scoring changes -- test commands or CI commands change - -## ADR trigger conditions - -Create or update an ADR when: - -- There are multiple reasonable architecture options. -- A decision changes module boundaries. -- A decision changes biological interpretation. -- A decision changes public API. -- A decision adds or removes a stage. -- A decision changes default safety behavior. -- A decision adds persistent side effects. - -## Progress reporting style - -Codex should keep progress compact and evidence-based: - -```text -Done: -- Added domain status enums and tests. -- Added BuildOptions groups with defaults. - -Verified: -- uv run pytest tests/unit/domain tests/unit/api -- uv run ruff check src tests - -Assumptions: -- MaterialState.PLANNED ranks below ASSEMBLED and above missing material. - -Next: -- Implement SbolResolver with PullPolicy.NEVER tests. -``` - -## When to stop and ask - -Stop and ask ChatGPT/user before: - -- Changing approval semantics. -- Changing level-1 cardinality. -- Supporting new part roles. -- Changing level-2 route scoring. -- Making graph scheduling drive execution. -- Making PUDU/Opentrons required. -- Adding persistent approvals. -- Adding DNA extraction as a real stage. diff --git a/AGENTS.md b/AGENTS.md deleted file mode 100644 index d0f1a31..0000000 --- a/AGENTS.md +++ /dev/null @@ -1,61 +0,0 @@ -# Developer Guide for AI Agents - -## ๐Ÿง  Mental Model - -BuildCompiler is a **workflow orchestrator**. - -Each function: -- Receives structured input -- Produces structured output -- Does not rely on hidden state - ---- - -## ๐Ÿ”‘ Core Entry Points - -- `index_collections` -- `domestication` -- `assembly_lvl1` -- `assembly_lvl2` -- `transformation` -- `plating` -- `full_build` - ---- - -## ๐Ÿ“ฆ Contracts - -Each function should: - -INPUT: -- SBOL or JSON - -OUTPUT: -- SBOL -- JSON -- Protocol files - ---- - -## โš ๏ธ Constraints - -- No hidden side effects -- Deterministic outputs -- Explicit file outputs - ---- - -## ๐Ÿงช Testing Expectations - -Each module must: -- Work independently -- Be testable with mock SBOL -- Validate outputs - ---- - -## ๐ŸŽฏ Goals for Contributions - -- Improve modularity -- Maintain pipeline clarity -- Avoid coupling biology logic with execution logic diff --git a/AGENTS_log.md b/AGENTS_log.md deleted file mode 100644 index c62ef9b..0000000 --- a/AGENTS_log.md +++ /dev/null @@ -1,301 +0,0 @@ -# BuildCompiler Agent Handoff Log - -Last updated: 2026-07-11 - -This log captures the recent BuildCompiler work so future agents can continue -without rediscovering the same repository and PUDU context. - -## Repository Mental Model - -BuildCompiler is a workflow orchestrator. Keep stages independently callable: - -- `index_collections` -- `domestication` -- `assembly_lvl1` -- `assembly_lvl2` -- `transformation` -- `plating` -- `full_build` - -Stage contracts should stay explicit: - -- Inputs: SBOL objects/documents or JSON payloads. -- Outputs: SBOL, JSON, and protocol files. -- Avoid hidden side effects except explicitly named output files. -- Prefer deterministic JSON ordering and deterministic generated artifacts. - -## Environment - -Primary tested environment: - -```bash -/Users/gonzalovidal/opt/anaconda3/bin/conda run -n GLLDB_py310 python ... -``` - -Useful commands: - -```bash -/Users/gonzalovidal/opt/anaconda3/bin/conda run -n GLLDB_py310 python -m pytest tests/unit/adapters/pudu/test_transformation_json.py tests/unit/adapters/pudu/test_plating_json.py tests/test_buildcompiler_transformation.py -``` - -`opentrons_simulate` is available inside `GLLDB_py310`: - -```bash -/Users/gonzalovidal/opt/anaconda3/bin/conda run -n GLLDB_py310 which opentrons_simulate -``` - -PUDU local source tree used for integration: - -```text -/Users/gonzalovidal/Documents/GitHub/PUDU -``` - -When using PUDU from notebooks/scripts without installing it, prepend: - -```python -sys.path.insert(0, "/Users/gonzalovidal/Documents/GitHub/PUDU/src") -``` - -## Recent BuildCompiler Changes - -### Transformation input normalization - -File: - -- `src/buildcompiler/buildcompiler.py` - -Added `_normalize_transformation_inputs()` so `BuildCompiler.transformation()` -accepts: - -- BuildCompiler `Plasmid` objects produced by `assembly_lvl1`/`assembly_lvl2`. -- Raw `sbol2.ComponentDefinition` plasmids. -- Dict payloads with `plasmid` or `plasmid_definition`. - -Reason: the active `BuildCompiler.transformation()` method referenced this -missing helper and failed when called with level-1 assembly products. - -Regression test: - -- `tests/test_buildcompiler_transformation.py::test_transformation_accepts_lvl1_assembly_products` - -### PUDU transformation adapter - -Files: - -- `src/buildcompiler/adapters/pudu/transformation_json.py` -- `src/buildcompiler/adapters/pudu/__init__.py` -- `tests/unit/adapters/pudu/test_transformation_json.py` - -Confirmed PUDU transformation spec shape: - -```json -[ - { - "Strain": "https://SBOL2Build.org/composite_strain_1/1", - "Chassis": "https://sbolcanvas.org/DH5alpha/1", - "Plasmids": ["https://SBOL2Build.org/composite_plasmid_1/1"] - } -] -``` - -Added `plasmid_locations_to_pudu_json()` for PUDU's assembly-output location map: - -```json -{ - "https://SBOL2Build.org/composite_plasmid_1/1": ["A1"] -} -``` - -This map is consumed by PUDU transformation protocol generation as -`--plasmid-locations transformation_input.json`. - -Note: the notebook now prefers the location map produced by simulating PUDU's -assembly protocol, because that is the real handoff in the PUDU workflow. - -### PUDU plating adapter - -Files: - -- `src/buildcompiler/adapters/pudu/plating_json.py` -- `tests/unit/adapters/pudu/test_plating_json.py` - -Updated `plating_to_pudu_json()` to match PUDU directly. PUDU expects -thermocycler well names as keys: - -```json -{ - "bacterium_locations": { - "A1": [ - "composite_strain_1", - "Competent_Cell_DH5alpha", - "composite_plasmid_1", - "Media_1" - ] - } -} -``` - -Removed the old nested `advanced_parameters` wrapper from the adapter output. -Optional advanced parameters now pass through as top-level PUDU parameters. - -## Notebook Added - -New notebook: - -```text -notebooks/buildcompiler_transformation_quickstart.ipynb -``` - -It demonstrates the full offline/PUDU chain: - -1. Load local SBOL collections: - - `tests/test_files/CIDARMoCloParts_collection.xml` - - `tests/test_files/CIDARMoCloPlasmidsKit_collection.xml` - - `tests/test_files/Enzyme_Implementations_collection.xml` - - `tests/test_files/impl_test_collection.xml` -2. Load `tests/test_files/abstract_design.xml`. -3. Run BuildCompiler `assembly_lvl1`. -4. Run BuildCompiler `transformation`. -5. Write BuildCompiler SBOL and JSON artifacts. -6. Generate PUDU assembly protocol. -7. Run `opentrons_simulate pudu_assembly_protocol.py`. -8. Use generated `transformation_input.json`. -9. Generate PUDU transformation protocol. -10. Run `opentrons_simulate pudu_transformation_protocol.py`. -11. Use generated `plating_input.json`. -12. Generate PUDU plating protocol. -13. Run `opentrons_simulate pudu_plating_protocol.py`. -14. Produce final `plating_layout.json` and `plating_layout.xlsx`. - -Important implementation detail: SBOL files are written with -`Document.writeString()` and `Path.write_text()` rather than `Document.write()` -to avoid PySBOL2's online validator in offline notebook runs. - -## Generated Notebook Artifacts - -Directory: - -```text -notebooks/results/buildcompiler_transformation_quickstart/ -``` - -Current generated files include: - -- `assembly_lvl1_pudu_input.json` -- `transformation_lvl1_products.xml` -- `transformation_products.xml` -- `transformation_summary.json` -- `transformation_lvl1_pudu_input.json` -- `pudu_assembly_protocol.py` -- `pudu_assembly_protocol.simulate.log` -- `transformation_input.json` -- `pudu_transformation_protocol.py` -- `pudu_transformation_protocol.simulate.log` -- `plating_input.json` -- `pudu_plating_protocol.py` -- `pudu_plating_protocol.simulate.log` -- `plating_layout.json` -- `plating_layout.xlsx` -- `Loop Assembly.xlsx` - -The simulation logs showed the expected handoff: - -- Assembly simulation generated `transformation_input.json`. -- Transformation simulation generated `plating_input.json`. -- Plating simulation generated `plating_layout.json` and `plating_layout.xlsx`. - -## PUDU Reference Points - -Local files inspected: - -- `/Users/gonzalovidal/Documents/GitHub/PUDU/docs/guide/workflow.rst` -- `/Users/gonzalovidal/Documents/GitHub/PUDU/docs/api/transformation.rst` -- `/Users/gonzalovidal/Documents/GitHub/PUDU/src/pudu/generate_protocol.py` -- `/Users/gonzalovidal/Documents/GitHub/PUDU/src/pudu/transformation.py` -- `/Users/gonzalovidal/Documents/GitHub/PUDU/src/pudu/plating.py` -- `/Users/gonzalovidal/Documents/GitHub/PUDU/workflow_example/transformation_spec.json` -- `/Users/gonzalovidal/Documents/GitHub/PUDU/workflow_example/transformation_input.json` -- `/Users/gonzalovidal/Documents/GitHub/PUDU/workflow_example/plating_input.json` - -PUDU's documented flow: - -```text -assembly_input.json - -> pudu_assembly_protocol.py - -> opentrons_simulate - -> transformation_input.json - -> pudu_transformation_protocol.py - -> opentrons_simulate - -> plating_input.json - -> pudu_plating_protocol.py - -> opentrons_simulate - -> plating_layout.json / plating_layout.xlsx -``` - -PUDU Python API used in notebook: - -```python -from pudu.generate_protocol import detect_protocol_type, generate_protocol -``` - -PUDU CLI equivalent: - -```bash -python -m pudu.generate_protocol assembly_input.json -o assembly_protocol.py --protocol-type assembly -opentrons_simulate assembly_protocol.py - -python -m pudu.generate_protocol transformation_spec.json -o transformation_protocol.py --protocol-type transformation --plasmid-locations transformation_input.json -opentrons_simulate transformation_protocol.py - -python -m pudu.generate_protocol plating_input.json -o plating_protocol.py --protocol-type plating -opentrons_simulate plating_protocol.py -``` - -## Validation Performed - -Notebook execution: - -```bash -/Users/gonzalovidal/opt/anaconda3/bin/conda run -n GLLDB_py310 python -c "import json; ns={}; nb=json.load(open('notebooks/buildcompiler_transformation_quickstart.ipynb')); [exec(''.join(cell.get('source', [])), ns) for cell in nb['cells'] if cell.get('cell_type') == 'code']" -``` - -Adapter and regression tests: - -```bash -/Users/gonzalovidal/opt/anaconda3/bin/conda run -n GLLDB_py310 python -m pytest tests/unit/adapters/pudu/test_transformation_json.py tests/unit/adapters/pudu/test_plating_json.py tests/test_buildcompiler_transformation.py -``` - -Last observed targeted results: - -- PUDU transformation/plating adapter tests: passed. -- BuildCompiler transformation regression tests: passed. -- Full notebook simulation chain: passed. - -## Current Worktree Notes - -At the time this log was written, expected modified/untracked files included: - -- `src/buildcompiler/adapters/pudu/__init__.py` -- `src/buildcompiler/adapters/pudu/transformation_json.py` -- `src/buildcompiler/adapters/pudu/plating_json.py` -- `src/buildcompiler/buildcompiler.py` -- `tests/test_buildcompiler_transformation.py` -- `tests/unit/adapters/pudu/test_transformation_json.py` -- `tests/unit/adapters/pudu/test_plating_json.py` -- `notebooks/buildcompiler_transformation_quickstart.ipynb` -- `notebooks/results/buildcompiler_transformation_quickstart/` -- `AGENTS_log.md` - -Do not revert unrelated user changes. If these files differ from this log, -inspect before editing. - -## Next Work Suggestions - -- Add a dedicated notebook/test for full-build output feeding the same PUDU - protocol chain. -- Decide whether generated notebook results should be committed or moved to an - ignored artifact path. -- Consider a higher-level BuildCompiler helper that returns all PUDU artifacts - for a stage chain without requiring notebook glue code. -- Add optional dependency documentation for PUDU and Opentrons simulation. -- Keep PUDU as optional unless the package is intentionally added as a dependency. diff --git a/PRODUCT.md b/PRODUCT.md index ffed963..c16b049 100644 --- a/PRODUCT.md +++ b/PRODUCT.md @@ -11,7 +11,6 @@ BuildCompiler should act like a compiler: inspect abstract designs, resolve depe - Synthetic biology researchers designing constructs in SBOL/SBOLCanvas/SynBioSuite. - Lab automation users generating manual or Opentrons-ready protocols through PUDU. - Developers extending BuildCompiler's planning, inventory, SBOL, or protocol-generation behavior. -- AI coding agents such as Codex implementing scoped refactor tasks from an approved plan. ## Jobs to be done @@ -29,7 +28,7 @@ BuildCompiler should act like a compiler: inspect abstract designs, resolve depe - Minimize new build work by searching inventory before generating new requests. - Keep compiler-only mode lightweight and testable. - Make optional automation outputs explicit, not default side effects. -- Provide a clean architecture that Codex can implement in small, safe increments. +- Provide a clean architecture that contributors can evolve in small, safe increments. ## Non-goals diff --git a/README.md b/README.md index 308e3e1..0286392 100644 --- a/README.md +++ b/README.md @@ -216,7 +216,7 @@ pytest tests/automation ## Container workflow -A Docker Compose workflow is recommended for reliable Codex and contributor development, but it does not need to block the first implementation PR. +A Docker Compose workflow is recommended for reliable contributor development, but it does not need to block the first implementation PR. Target commands after Docker support exists: @@ -252,13 +252,14 @@ Testing priorities: 9. Summary/report/graph generation. 10. Optional PUDU/Opentrons adapter smoke tests. -## How ChatGPT and Codex should use these docs +## Project documentation - `PRODUCT.md` defines the product intent, v1 scope, and non-goals. - `ARCHITECTURE.md` defines module boundaries and implementation contracts. -- `AGENT.md` defines how Codex should take tasks, report progress, and escalate decisions. - `ADR-001.md` records the clean-architecture rewrite decision and its tradeoffs. -Codex should treat these files as the source of truth for implementation unless the user or ChatGPT explicitly revises them. + +Contributors should keep these documents aligned with changes to product scope, +architecture, or public behavior. #### Running tests locally: Run these bash commands to establish your SynBioHub account for collection access. These are saved in GitHub secrets for the automated test suite. @@ -270,4 +271,3 @@ Run these bash commands to establish your SynBioHub account for collection acces Then run the tests with: `uv run python -m unittest discover -s tests` - diff --git a/docs/development.rst b/docs/development.rst index 91c5211..d86c12b 100644 --- a/docs/development.rst +++ b/docs/development.rst @@ -26,12 +26,12 @@ Build docs locally: python -m pip install -r docs/requirements.txt sphinx-build -b html docs docs/_build/html -Agent handoff -------------- +Project documentation +--------------------- -Repository-specific agent instructions are in ``AGENTS.md``. Recent handoff -notes for the PUDU integration and notebook artifacts are in -``AGENTS_log.md``. +The repository root contains ``PRODUCT.md`` for product scope, +``ARCHITECTURE.md`` for module boundaries and implementation contracts, and +``ADR-001.md`` for the clean-architecture decision and its tradeoffs. Read the Docs deployment ------------------------