Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
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
277 changes: 277 additions & 0 deletions AGENTS.md
Comment thread
Scienfitz marked this conversation as resolved.
Comment thread
Scienfitz marked this conversation as resolved.
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems like you have a no fallback rule.

I have run into issues with this before, here's my section about it:

## Zero Fallback Principle
Execution MUST abort immediately on any missing dependency, malformed data field, absent required column/key, unexpected enum value, or structural schema mismatch. Do **not** continue in a degraded or "best effort" mode. No silent defaults. No guessing. Expensive downstream computation must be prevented when prerequisites are not perfectly satisfied.


## Validation Philosophy
- **Per-Template Strict Validation**: Each template defines exact allowed factor choices; models cannot select factors outside their template.
- **Validation at Inference Time**: PromptSwarm validates outputs using the universal `ConditionRecommendationModel` with the template's `_allowed_choices` passed as validation context.
- **Zero Fallback**: Any validation failure TERMINATES that template's inference (circuit breaker pattern in promptswarm).
- **No Partial Results**: Invalid outputs are not written to the WFM database; no partial pipelines or continued processing.

Then I also have a hook that autodetects when Claude is trying to add a fallback and stops him:

https://github.com/merckgroup/condition_rec_benchmarking/blob/main/.claude/hooks/check-fallback.sh

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've extracted some generalizable principles out of this and added to the file under the respective sections (590b521)

well discuss whether we can do something with the actual hook as well, in any case thanks for your input 🙌

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

via Kevin: Rename to CLAUDE.md + symlink for other tools

Consider making CLAUDE.md the canonical file (auto-loaded by Claude Code, supports subdirectory scoping). Symlink AGENTS.md and .github/copilot-instructions.md to it so all three tools share a single source of truth.

Copy link
Copy Markdown
Collaborator Author

@Scienfitz Scienfitz Mar 30, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@LeanAndMean not sure if I got your suggestions because that was already fully the idea of the AGENTS.md files. Afaik tools like claude or opencode alreayd recognize AGENTS.md (including auto-context-ingestion and subdirectory scoping) and do not really need CLAUDE.md or any other more specifically named file.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also would not tailor the file too strictly to Claude. Even though the majority of people might use claude by now, I would prefer to keep it general as other people might use other tools. Not sure if people might think "Oh no, I have to use Claude when working with Agentic AI and BayBE" which I'd like to avoid.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK Claude Code CLI will only operate "properly" if you use the CLAUDE.md convention. Here's what Claude Code CLI had to say about it, after reviewing its own usage guide:

❯ Research whether Claude Code CLI recognizes AGENTS.md in the absence of CLAUDE.md

● claude-code-guide(Research AGENTS.md recognition)
  ⎿  Done (5 tool uses · 40.6k tokens · 23s)
  (ctrl+o to expand)

● Claude Code does not recognize AGENTS.md — it only loads CLAUDE.md files.

  Details

  - AGENTS.md is a convention used by other coding agents (e.g., Cursor, Copilot), not Claude Code.
  - Claude Code looks for CLAUDE.md in these locations:
    - ./CLAUDE.md or ./.claude/CLAUDE.md (project root)
    - ~/.claude/CLAUDE.md (user home)
    - Subdirectories (loaded on demand when entering them)
  - If CLAUDE.md doesn't exist, Claude Code simply has no project instructions — it does not fall back to AGENTS.md.

  If you need both

  You can bridge them using the @ import syntax in CLAUDE.md:

  @AGENTS.md

  ## Claude-specific instructions
  ...

  This way both tools share the same base instructions without duplication.

  Sources:
  - https://code.claude.com/docs/en/memory.md

Using @AGENTS.md in CLAUDE.md is another option - it inlines the file contents directly. I go with symlinks because they don't rely on any code harness supporting inlining files (a more futureproof strategy).

The unfortunate truth is that Claude was first, created CLAUDE.md, then the industry followed, creating AGENTS.md (similar to Nvidia with CUDA, and everyone else with OpenCL). The only way to not impose using one coding harness over another is to have both in your library.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The day may come with Claude Code CLI supports AGENTS.md, but it is not this day.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmmk wasnt aware of that (using opencode myself) - surprising to say the least (maybe now that the source code got hacked they'll include it somehow :)

in that case CLAUDE.md with symlink is the obvious goto

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

via Kevin: Add a commands/validation section

The current file covers conventions but doesn't tell the agent how to validate its work. Add a commands section covering install, test (pytest --fast, pytest -k "test_name"), lint, typecheck, and tox environments (including tox -e mypy-py310 and tox -p for parallel).

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the idea maybe we could put that in or expand CONTROBUTING and link it in AGENTS

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like having some important example commands in AGENTS.md is important for also showing AI agents how to use your library the way you do, but your mileage may vary.

The best way to figure this out is with testing. Try developing with and without this change - see if you can tell the difference. If you can't, then it doesn't need to be in there.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

via Kevin: Add an architecture-to-filepath mapping

Map each core domain concept to its file path (e.g. Campaign → baybe/campaign.py, SearchSpace → baybe/searchspace/). Gives agents "what is this" and "where to find it" in one pass.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be helpful for reducing the search time for agents as well as reducing the number of times they decide to not look for something when they should.
My policy is just to use the default /init with Claude Code CLI, then tell Claude to add/update the filepath mapping if I see it struggling to find things (or after major changes to the repo).

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

via Kevin: Distill key design principles for agents

Highlight the 2–3 principles agents are most likely to violate: comp-rep boundary, lazy imports ("non-negotiable"), and the serialization pattern. Complements the fuller treatment already in the file.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This tends to reduce the amount of human interventions and corrections you need to perform while developing. If the agents know your value system, it will tend to produce things closer to what you're looking for, and it requires less human effort to get a high quality result. Often, >99% of developers values are aligned, so you don't need to tell it that (E.g., "Don't write bugging code"). It tends to be when there's multiple viable options (E.g., Do we want fallbacks or not?) when it becomes necessary to define your terms. The "best" AGENTS.md/CLAUDE.md will contain only the things necessary to get the desired behavior. It's a waste of tokens to tell AI agents to do something they were going to do anyway.

Again, only through testing will you figure out what the right balance is, because it's not clear what values they hold implicitly in different situations.

Comment thread
Scienfitz marked this conversation as resolved.
Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

via Kevin and Drew: Add concrete examples to anti-pattern rules

Rules like "prefer local fixtures" are easier for agents to follow with a one-liner showing the preferred pattern. Even minimal examples help.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The links in this file curretly break doc building. We could either exclude it fully from the documentation or only from linkcheck, as I think trying to adjust the links such that they work in the compiled doc might then not make sense for the agents anymore (but we could also try this)). Opinions?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should be excluded

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • testing guidelines missing?
  • I would also add a small collection of the main abstractions in BayBE (e.g. Campaign, Parameter, ...) so that the AI has the big picture of your package semantics

Original file line number Diff line number Diff line change
@@ -0,0 +1,277 @@
# BayBE Coding Guide for AI Agents

## 1. Project Overview
**BayBE** (Bayesian Back End) is a Python library for Bayesian optimization and
experimental design. It targets Python 3.10+.

### Tech Stack
| Role | Library |
|------|---------|
| Data modeling | `attrs` (`@define`) |
| Serialization | `cattrs` + custom `SerialMixin` |
| Bayesian optimization | `botorch`, `gpytorch` |
| Tensor backend | `torch` |
| Numerics | `numpy`, `pandas`, `scipy`, `scikit-learn` |
| Testing | `pytest`, `hypothesis` |
| Linting/formatting | `ruff`, `mypy`, `pydoclint`, `pyupgrade` |

### Directory Layout
- `baybe/` — Main source package with many subpackages containing structures and objects
such as parameters, constraints, targets, etc.
- `tests/` — Test suite. `conftest.py` has the central fixture system.
- `docs/` — Sphinx documentation (Furo theme, MyST-Parser). `docs/userguide/` has
concept-oriented pages.
- `examples/` — Runnable example scripts (jupytext percent format).
- `benchmarks/` — Benchmarking framework.
- `.github/workflows/` — CI/CD (lint, test, docs, release, benchmark).

## 2. Architecture and Design Principles
- Campaign is the single stateful class: All other domain objects are frozen or
stateless after construction. Do not add mutable state outside `Campaign`
- Comp-rep vs. exp-rep boundary: The comp-rep transition happens in the surrogate
layer, not the recommender. `comp` is reserved for this — never reuse it for
"component" or "comparison"
- Composition over monolith: Use builder pattern (e.g., acquisition functions) and
factory classmethods (`from_product`, `from_dataframe`, `from_parameter`) instead of
if-else chains
- Explicit over implicit: No silent errors — raise immediately. Validate eagerly
at construction time. Side effects after validation only. Never fall back to
degraded or "best effort" mode — if a dependency is missing, data is malformed,
or a precondition is not met, abort. Fail before expensive downstream
computation (surrogate fitting, acquisition optimization) when prerequisites
are not satisfied
- Separation of concerns: Target transformation ("what/how to transform") is
separate from objective ("how to combine targets"). Surrogate owns data
scaling/transformation; recommender owns recommendation logic.
- Design for generalizability. Keep fields private when API may change
- Keep classes focused — attributes relevant to the general case only
- Prefer BayBE types over raw external types in interfaces
- Keep raw data types consistent; defer conversions to point of use

## 3. Class Design
### attrs Only
All domain classes use `attrs` `@define`. No dataclasses, no Pydantic.
- Immutable value objects (parameters, kernels, priors, transformations, objectives,
targets): `@define(frozen=True, slots=False)`.
- Mutable stateful objects (campaign, surrogates, recommenders): `@define`.
- `slots=False` required with `frozen=True` when `cached_property` is needed. See
`attrs` issue #164
- Also use `slots=False` when monkeypatching is needed (e.g., `register_hooks`)

### Inheritance: ABC + SerialMixin + Protocol
1. `Protocol` (`@runtime_checkable`): External/duck-typed interfaces. Always
`__slots__ = ()`.
2. ABC: Shared behavior. Inherits from `ABC` and `SerialMixin`
3. Concrete classes: Inherit from ABC.

### Fields and Methods
- Use `field()` with `validator=`, `converter=`, `default=`, `factory=`, `alias=`.
- Private fields: `_` prefix, typically `init=False`.
- Store each piece of information once — no data duplication.
- Use `attrs.evolve()` for modified copies of frozen objects.
- Use `on_setattr` hooks for cache invalidation on mutable objects.
- `ClassVar[bool]` for capability flags (`supports_transfer_learning`, etc.).
- Order class content like this: 1) Attributes, 2) validators and post_init, 3)
properties, 4) methods. Within each group use alphabetical order.

### Attribute Docstrings
String literals immediately below field declarations, blank lines between attributes.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

add example?


### Module Epilogue
Every module using `@define` must end with:
`gc.collect()` with comment "Collect leftover original slotted classes..."
Comment thread
Scienfitz marked this conversation as resolved.

### Factory Classmethods
Name descriptively: `from_product`, `from_dataframe`, `from_parameter`, `from_config`,
`from_json`, `from_dict`, `from_preset`.

### classproperty
Custom `@classproperty` from `baybe.utils.basic` for class-level computed properties.

## 4. Naming Conventions
| Element | Convention | Examples |
|---------|------------|---------|
| Variables/functions | `snake_case` | `batch_size`, `add_measurements` |
| Classes | `PascalCase` | `Campaign`, `BotorchRecommender` |
| Constants | `SCREAMING_SNAKE_CASE` | `_RECOMMENDED`, `_TYPE_FIELD` |
| Private members | `_` prefix | `_cached_recommendation`, `_fit()` |
| Booleans | `is_`/`has_`/`supports_` | `is_numerical`, `supports_transfer_learning` |
| Counts | `n_` prefix | `n_batches_done`, `n_grid_points` |
| Protocols | `Protocol` suffix | `RecommenderProtocol` |
| Default/validator methods | `_default_<attr>` / `_validate_<attr>` | |

### Reserved Terminology
| Term | Reserved Meaning |
|------|----------------------------------------------------------------|
| `task` | Transfer learning context only |
| `comp` / `comp_rep` | Computational representation |
| `exp_rep` | Experimental representation |
| `configuration` | Assignment of values to ALL parameters (not individual values) |

### Abbreviations
- Full words in public API: `searchspace`, `objective`, `measurements`.
- Short forms in local contexts: `df`, `p` (parameter), `t` (target), `rec`.
- Established: `comp_rep`, `exp_rep`, `acqf`.

### Additional Rules
- Use `self.__class__.__name__` not hardcoded class names in errors/repr.
- No private field names (`_attr`) in user-facing messages — use
`fields(type(self)).attr.alias`.
- Method names start with verbs. Comments capitalize first word.

## 5. Type Annotations
- **Full coverage**: All signatures including returns. Every field annotated.
- Uses `from __future__ import annotations` where needed (PEP 563).
- Modern syntax: `X | Y` (not `Union`), `X | None` (not `Optional`).
- `TypeAlias` for complex types, `ClassVar[T]` for class metadata.
- `TypeVar` with `_co` suffix for covariant. `Literal[...]` for constrained strings.
- `NoReturn` for deprecation properties that always raise.
- Always use `@typing_extensions.override` on overridden methods (enforced by
mypy `explicit-override`).
- Use positional-only (`/`) and keyword-only (`*`) markers where appropriate.
- Heavy/optional imports for type annotations go in `if TYPE_CHECKING:` blocks.
- `# type: ignore` must include specific error code and explaining comment.
- Use `==` for equality, `is` for identity/sentinels. Prefer `tuple` over `list` for
immutable returns. Prefer generic types (e.g., `Collection` over `Sequence` when
only `in` is needed).

## 6. Import Conventions
- Order (enforced by ruff isort): `__future__` | stdlib | third-party | local.
`import X` before `from X import ...` within each group.
- Lazy imports: `torch`, `botorch`, `gpytorch`, `scipy`, `sklearn` must be
lazy-loaded inside function bodies. CI tests assert `torch` is not loaded after
importing BayBE objects. Non-negotiable.
- `TYPE_CHECKING` guard: Imports only for annotations go inside
`if TYPE_CHECKING:`.
- Aliasing: BoTorch types use `Bo` prefix (e.g., `BoAcquisitionFunction`).
- Remove unused imports immediately. Module-level imports preferred except for
optional dependency gating.

## 7. Docstring and Comment Style
### Google-Style Docstrings (enforced by ruff + pydoclint)
- Module: One-line description.
- Class: Describe purpose. Attribute docs go below each field, not in class
docstring.
- Method/function: `Args:`, `Returns:`, `Raises:` sections.
- Types from annotations only (not in docstrings). All raised exceptions documented.
- Imperative mood for summary line (D401). D105/D107 exempted.
- Even private properties and `cached_property` need docstrings.
- Overridden methods inherit docstrings via `@override`.
- Sphinx roles for cross-refs: `:func:`, `:class:`, `:meth:`. Double backticks for
literals.
- Attrs validators get `# noqa: DOC101, DOC103` (pydoclint confused by
`(self, attribute, value)` signature).
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

add example?


### Comment Patterns
- `# TODO:` — planned improvements.
- `# IMPROVE:` — enhancement ideas (project-specific).
- `# FIXME[tag]:` — known problems.
- `# NOTE:` — important context.
- `##### Section #####` separators in rare occasions where justified.
- `# >>>>>>>>>> Deprecation` / `# <<<<<<<<<< Deprecation` block delimiters.
- Do not use other comment styles such as `-----`.

## 8. Error Handling
- Custom errors and warnings can be found in `baybe/exceptions.py`.
- f-strings with self-documenting expressions: `f"{batch_size=}"`.
- Always chain exceptions: `raise ... from ex`.
- No partial results: Either the full operation succeeds or it raises. Invalid
inputs must not produce partial or silently degraded outputs.
- Warnings originate at source level. Use specific warning classes, not bare `Warning`.

## 9. Serialization
- Built on `cattrs` with central global `Converter` in `baybe/serialization/core.py`.
- `SerialMixin` provides `to_dict()`/`from_dict()`, `to_json()`/`from_json()`.
- Polymorphic deserialization via `"type"` field on abstract bases.
- DataFrames serialized via pickle + base64.
- `Campaign` includes `"version"` field. `"constructor"` key enables alternative
classmethod deserialization.
- Register custom cattrs hooks at module level after class definition.
- Always copy caller-provided dicts before `pop()`/mutation.

## 10. Deprecation Strategy
Three tiers:
1. Soft: `warnings.warn(..., DeprecationWarning)` — message says what to use
instead and when removal happens.
2. Hard: `DeprecationError` — fully removed features that must interrupt execution.
3. Serialization-level: Custom cattrs hooks redirect legacy class names.

- Deprecated class names become wrapper functions that warn and delegate.
- Mark blocks with `# >>>>>>>>>> Deprecation` / `# <<<<<<<<<< Deprecation`.
- Old env var names auto-translated with warning at settings init.
- Private cross-module imports acceptable temporarily during deprecation; clean up
when expired.
- Test in `tests/test_deprecations.py`.

## 11. Validation Patterns
- Inline validators: `field(validator=(instance_of(str), min_len(1)))`, `in_()`,
`deep_iterable()`, custom `finite_float`, `gt()`.
- Method validators: `@_field.validator` with `# noqa: DOC101, DOC103` for
validators needing `self` access.
- Cross-field: `__attrs_post_init__` when validation involves multiple fields.
- Converters: `field(converter=to_searchspace)` for automatic type coercion.
- Reusable validators in `baybe/utils/validation.py`: `finite_float`,
`non_nan_float`, `non_inf_float`, `validate_not_nan`, `validate_target_input`,
`validate_parameter_input`, `validate_object_names`.
- Cache invalidation: `on_setattr` hooks on mutable fields.

## 12. Optional Dependencies
1. Detection (`baybe/_optional/info.py`): `importlib.util.find_spec()` sets boolean
flags (`CHEM_INSTALLED`, `ONNX_INSTALLED`, etc.) without importing.
2. Guarded imports (`baybe/_optional/<dep>.py`): Import or raise
`OptionalImportError` with pip install instructions.
3. In tests: `@pytest.mark.skipif(not CHEM_INSTALLED, ...)`. Use `pytestmark` for
module-level skips.

## 13. Public API
- Every package defines `__all__` (always a `list`). Only concrete user-facing classes
exported.
- Top-level exports: `Campaign`, `Settings`, `active_settings`, `__version__`.
- Subpackage `__init__.py` re-exports for convenient imports.
- Aliases allowed (e.g., `EI = ExpectedImprovement`).

## 14. Tooling and CI
| Tool | Config | Purpose |
|------|--------|---------|
| `ruff` | `ruff.toml` | Lint (D, E4, E7, E9, E501, F, I, W, PL) + format. Line length 88. |
| `flake8`+`pydoclint` | `pydoclint.toml` | Docstring consistency (DOC rules only) |
| `mypy` | `mypy.ini` | Type checking. `explicit-override`, `unused-ignore` enabled. |
| `pyupgrade` | `.pre-commit-config.yaml` | Python 3.10+ syntax |

Pre-commit hooks: pydoclint, ruff (lint+format), uv-lock, pyupgrade.
Tox environments: `fulltest`, `coretest`, `lint`, `mypy`, `audit`, `docs`.
Coverage: 70% overall, 45% per-file minimum.
CI runs on push/PR to `main`/`dev/**`: changelog check, lint, typecheck, audit,
coretest, fulltest. Docs and benchmarks on releases.
For each development, ensure `tox -e mypy-py310` runs without problems.

## 15. Git and PR Workflow
- Feature branches from `main`. `dev/**` for development. Naming: `bug/`, `refactor/`,
`feature/`, `benchmarks/`, `docs/`.
- Rebase preferred for linear history.
- CHANGELOG.md updated in every PR (CI enforced). Specific entries, complete
sentences. Commit named "Update CHANGELOG" as last commit.
- Use imperative in commit header, e.g. "Add", "Fix", "Rework", "Handle", "Adjust", etc.
- Keep commit body short and informative. Do not add commit body if it has no
additional info compared to the header.
- Pre-commit must pass. Clean history: squash add/revert pairs, no debug prints.
- Create a separate commit for logical steps, neither per-file nor one giant commit.
- When implementing a fix for some pre-existing issue, make a separate commit with
explanation.

## 16. Anti-Patterns to Avoid
- No monolithic if-else chains — use builder/strategy patterns.
- No position-based argument matching — use name-based.
- No dead/unreachable code.
- No data duplication.
- No eager imports of heavy deps (torch, scipy, sklearn, botorch) — lazy-load.
- Do not mix reserved terminology (`task` = TL only, `comp` = comp-rep only).
- No hardcoded enum values in comments — link the enum.
- No private field names in user-facing messages — use public alias.
- No hardcoded class names in repr/errors — use `self.__class__.__name__`.
- No silent errors. No mutation of caller-provided dicts.
- No silent defaults or "best effort" fallbacks — if input is invalid, raise.
- No proceeding past failed preconditions into expensive computation.
- No stale cross-references. No inconsistent terminology in docstrings.
- No conftest pollution — prefer local fixtures.
- Tests must test what they claim. No duplicated test logic — parametrize.
5 changes: 5 additions & 0 deletions baybe/exceptions.py
Original file line number Diff line number Diff line change
@@ -1,5 +1,6 @@
"""Custom exceptions and warnings."""

import gc
from typing import Any

import pandas as pd
Expand Down Expand Up @@ -172,3 +173,7 @@ class InvalidTargetValueError(Exception):

class NotAllowedError(Exception):
"""An operation was attempted that is not allowed in the current context."""


# Collect leftover original slotted classes processed by `attrs.define`
gc.collect()
38 changes: 38 additions & 0 deletions docs/AGENTS.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,38 @@
# AGENTS.md — BayBE Documentation Conventions

## Toolchain
Sphinx + Furo theme + MyST-Parser (Markdown). Also: sphinx-autodoc-typehints,
sphinxcontrib-bibtex, jupytext (example conversion), autosummary (API reference).
Config in `docs/conf.py`.

## Structure
- `docs/userguide/` — Concept-oriented pages (campaigns, parameters, targets,
objectives, constraints, etc.)
- `docs/faq.md` — FAQ with dropdown directives
- `docs/known_issues.md` — Known issues with fix suggestions
- `docs/templates/` — RST templates for autosummary
- `docs/scripts/` — Build scripts (`build_documentation.py`, `build_examples.py`)

## User Guide
- Contains explanations for high-level concepts
- Provides runnable code snippets, uses admonitions, links to relevant examples. Keep
the snippets very concise
- Use fenced code blocks with triple backticks (e.g. ```python) for runnable code that
is also tested in the doc tests
- Use fenced code blocks with tildes (e.g. ~~~python) for code examples that cannot be
tested, e.g. if they reference objects that do not exist within the snippet or the
test fixtures

## MyST Syntax Reference
- Cross-refs: "{class}`~baybe.campaign.Campaign`",
"{meth}`~baybe.campaign.Campaign.recommend`", "{doc}`/userguide/campaigns`".
The `~` shortens display to final component
- Admonitions: `{admonition} Title` with `:class: note|important|tip|warning|caution|info`.
- Anchors: `(ANCHOR_NAME)=` above a heading, reference via "{ref}`ANCHOR_NAME`".
- For math use: `$...$` inline, `$$...$$` display, `{math}` directive.

## Writing Style
- Precise wording ("possible" vs "optional" — "optional" has typing meaning).
- Use consistent terminology within a page (don't mix `search space` / `searchspace` /
`SearchSpace`).
- Double backticks for literals. Keep cross-references up-to-date when paths change.
30 changes: 30 additions & 0 deletions examples/AGENTS.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,30 @@
# AGENTS.md — BayBE Example Conventions

## Format
Examples are `.py` files, converted to notebooks, executed, then rendered as Markdown
in Sphinx docs. Must be syntactically valid, runnable end-to-end, and fast in CI via
`SMOKE_TEST`.

## Structure
Every example follows this pattern:
1. Title: `# # Short Descriptive Text in Telegraph Style`
Comment thread
Scienfitz marked this conversation as resolved.
2. Introduction: Comment lines describing what the example demonstrates
3. Section headers: `## Subheading` in comments
4. Imports: stdlib / third-party / BayBE / example utils (same ordering as main
codebase)
5. SMOKE_TEST: `SMOKE_TEST = "SMOKE_TEST" in os.environ` then conditional
constants: `N_DOE_ITERATIONS = 2 if SMOKE_TEST else 20`
6. Constants: `SCREAMING_SNAKE_CASE` (`DIMENSION`, `BATCH_SIZE`)
7. Inline docs: Explanatory comments between code blocks
8. Print results: `print(recommendation)`
9. Fake measurements: Non-simulation examples use
`add_fake_measurements(recommendation, campaign.targets)`

## Cross-References
You can embed Sphinx admonitions and cross-references in comments:
"# See {class}`~baybe.campaign.Campaign` for details."

## Directory Layout
Organized by category (`Basics/`, `Backtesting/`, `Constraints_Continuous/`,
`Multi_Target/`, `Serialization/`, `Transfer_Learning/`, etc.). Each category has a
`*_Header.md` for the docs toctree. Shared utilities in `examples/utils.py`.
Loading
Loading