You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CLAUDE.md
+39-32Lines changed: 39 additions & 32 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,39 +1,47 @@
1
1
# Instructions for AI agents
2
2
3
-
This is a Python implementation of the Cyphal decentralized real-time publish-subscribe protocol. The key design goals are **simplicity** and **robustness**.
3
+
This is a Python implementation of the Cyphal decentralized real-time publish-subscribe protocol.
4
+
The key design goals are **simplicity** and **robustness**.
5
+
Avoid overengineering and complexity; prefer straightforward solutions and explicit code.
4
6
5
-
All features of the library MUST work on GNU/Linux, Windows, and macOS; the CI system must ensure that. Supported Python versions are starting from the oldest version specified in `pyproject.toml` up to the current latest stable Python.
7
+
All features of the library MUST work on GNU/Linux, Windows, and macOS; the CI system must ensure that.
8
+
Supported Python versions are starting from the oldest version specified in `pyproject.toml` up to the current
9
+
latest stable Python.
6
10
7
-
To get a better feel of the problem domain, peruse `reference/cy`, especially the formal models and the reference implementation in C.
11
+
Rely on the Python type system as much as possible and avoid dynamic typing mechanisms;
12
+
for example, always use type annotations, prefer dataclasses over dicts, etc.
8
13
9
-
## Code layout
14
+
To get a better feel of the problem domain, peruse `reference/cy`,
15
+
especially the formal models and the reference implementation in C.
10
16
11
-
Source is in `src/pycyphal/`, tests in `tests/`. The package is extremely compact by design and has very few modules:
17
+
## Architecture and code layout
12
18
13
-
-`_common.py` — Exception hierarchy, utilities, etc.
-`__init__.py` — Public API re-exports from the above modules.
18
-
- Concrete transports:
19
-
-`udp.py` — Cyphal/UDP transport implementation.
19
+
Source is in `src/pycyphal/`, tests in `tests/`. The package is extremely compact by design and has very few modules.
20
20
21
-
Internal implementation modules use leading underscores. Keep public symbols explicit through `__init__.py`; keep private helpers in underscore-prefixed modules.
21
+
Concrete transports are in top-level submodules:
22
+
-`pycyphal.udp` — Cyphal/UDP transport implementation.
23
+
-`pycyphal.can` (coming soon, not yet in the codebase) — Cyphal/CAN transport implementation.
22
24
23
-
## Architecture
25
+
The core must be dependency-free. Transports may introduce (optional) dependencies.
24
26
25
-
The stack is layered: **Transport** (abstract I/O) → **Wire** (framing/headers) → **Node** (session logic). `Node` is the main user-facing class that ties everything together.
27
+
Internal implementation modules use leading underscores.
28
+
Keep public symbols explicit through `__init__.py`; keep private helpers in underscore-prefixed modules.
29
+
The application is expected to `import pycyphal` only, without reaching out for any submodules directly;
30
+
one exception applies to the transport modules mentioned above because the application will only import the transports
31
+
that it needs.
26
32
27
-
Key mechanisms in `Node`:
28
-
-**CRDT**: Management of the distributed topic allocation table. Topics map to subject IDs via rapidhash; collisions are resolved by deterministic eviction.
29
-
-**Gossip**: Periodic and urgent data exchange to keep CRDT consistent.
30
-
-**Deduplication, Reordering, Reliable delivery** of user messages.
31
-
32
-
Use `nox` to run the full test suite.
33
+
Since the entirety of the library API is explicitly exposed through `pycyphal/__init__.py`,
34
+
internally the library is free to use public visibility for all symbols/members that may require shared access
35
+
between modules, even if they are not intended for external use.
36
+
In particular, DO NOT access underscore-prefixed symbols from other modules/classes,
37
+
but feel free to use non-underscore-prefixed symbols internally as needed, as there is no risk of API contamination.
33
38
34
39
## Reference design
35
40
36
-
`reference/` contains git submodules with the reference implementations in C of the session layer (`cy/`) and Cyphal/UDP transport layer (`libudpard/`). These serve as the ultimate source of truth shall any wire-visible discrepancies be found.
41
+
`reference/` contains git submodules with the reference implementations in C of the session layer (`cy/`)
42
+
and transport layers (like `libudpard/` etc).
43
+
These serve as the ultimate source of truth shall any wire-visible discrepancies be found.
44
+
If there is a divergence between the references and this Python library, assume this Python library to be wrong.
37
45
38
46
For parity audits or sync work against the reference, use the repo-local skill `$cyphal-parity-guard`.
39
47
Expected usage patterns:
@@ -48,23 +56,22 @@ All I/O is async/await (pytest-asyncio with `asyncio_mode="auto"`).
48
56
The code is fully type-annotated; frozen dataclasses for data.
49
57
Dependencies intentionally kept to the bare minimum.
50
58
51
-
For agent-authored commits, set `GIT_AUTHOR_NAME="Agent"` and `GIT_COMMITTER_NAME="Agent"`.
52
-
53
59
### Testing
54
60
55
-
Mock transport/network in `tests/conftest.py`. Tests are ~10x the size of source code.
61
+
Mock transport/network in `tests/conftest.py`.
62
+
Tests are x10+ the size of source code and must provide full coverage of the core.
63
+
Transport test coverage is more opportunistic.
56
64
57
65
### Logging
58
66
59
-
Logging is required throughout the codebase; prefer many short messages.
60
-
61
-
Avoid adding logging statements on code paths that immediately raise/enqueue/schedule an error as they are often redundant.
62
-
Level policy:
67
+
Logging is required throughout the codebase; prefer many short messages. Avoid adding logging statements on code
68
+
paths that immediately raise/enqueue/schedule an error as they are often redundant.
69
+
Follow `getLogger(__name__)` convention.
70
+
Logging policy:
63
71
64
-
- DEBUG for super detailed traces. Each DEBUG logging statement must occupy at most one line of code. Use abbreviations and formatting helpers.
72
+
- DEBUG for super detailed traces. Each DEBUG logging statement must occupy at most one line of code.
73
+
Use abbreviations and formatting helpers.
65
74
- INFO for anything not on the hot data path. Each INFO logging statement should take at most 2 lines of code.
66
75
- WARNING for anything unusual. No LoC restriction.
67
76
- ERROR for errors or anything unexpected. No LoC restriction.
68
77
- CRITICAL for fatal or high-severity errors. No LoC restriction.
0 commit comments