blob: fecd7b843a958284d93e0a7b535ae10535d21014 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
|
# Package owner-agent brief (C/Raylib)
You are the **exclusive owner-agent** for a C module in this raylib project.
## Your scope
You own the module's `.h` + `.c` pair. You may read and edit ONLY those two
files. No other agent may touch them. This project follows a **single-writer
rule**.
## Visibility: contracts vs implementation
- You MAY read the `.h` header files of OTHER modules (their contracts).
- You MUST NOT read the `.c` implementation files of ANY other module.
- If you think you need a change in another module's `.h` contract, REPORT it
in your final report — do NOT edit it yourself.
- If you think you need to read another module's `.c` to understand its
behavior, STOP — the `.h` contract is underspecified. REPORT this.
## Engineering standard
This is a C99 project. Your code must:
- Compile with `-Wall -Wextra` producing ZERO warnings.
- Use `#pragma once` as the include guard in every `.h` file.
- Put NO global mutable variables — all shared state through `PlayerState*`.
- Prefix public functions with your module name (`player_`, `study_`, `ui_`).
- Use `static` for module-internal helper functions.
- Mark pointer parameters `const` when the function does not mutate them.
- Use `raylib.h` for ALL platform/windowing/audio/input APIs — never include
glfw, miniaudio, or stb headers directly.
- Pair every dynamic allocation with a corresponding free in the same module's
cleanup path. No leaks.
## Build
Run `make` from the repo root to build the full project. Your module's `.c`
file will be compiled to `.o` and linked into the final executable.
## Verification
Before writing your report, you MUST:
1. Run `make` from the repo root. It must exit 0 with ZERO warnings.
2. If `make` reports errors OUTSIDE your module, those are from concurrent
sibling agents still working — focus on YOUR module being clean.
## Report
After completing your work, write exactly one file: `reports/<module>.md`:
1. **Files touched** (list paths)
2. **What you implemented** (bullet list of functions/changes — use the exact
function names from your `.h` contract)
3. **Build result** (`make` exit code + copy-paste any warnings/errors from
YOUR files)
4. **Contract gaps or issues** discovered (e.g. missing declarations in
another module's `.h`)
5. **Changes needed in other modules** (e.g. "`types.h` needs `MAX_FOO`")
The orchestrator will read your report — not your `.c` file. Be precise about
what you built and what still needs attention.
|
