01 / House vocabulary
One word, with its exceptions enumerated
The term uses title case in prose. Literal code tokens keep their original spelling, including inside fenced blocks, and anti-pattern quotes may show the wrong form when teaching the rule.
Source excerpt starting at line 8.8Write **Dag** (title case) in all prose. Keep the all-caps or lowercase9spelling only when reproducing a literal code token — never rewrite these,10even inside fenced code blocks:
02
How to classify a security finding
The guide separates security findings into vulnerabilities, known limitations, and deployment hardening. It links the security model, including the chapter that defines what is not a vulnerability.
03 / Contribution etiquette
Open the pull request, not the issue
Known fixes go straight to a pull request to avoid duplicate work. Deferred fixes still need an issue that outlives the workaround.
Source excerpt starting at line 368.368- Open issues attract drive-by submissions, often from other agents, that369 haven't seen the in-flight work. That produces duplicate fixes, low-quality
04
Deferred work linked from the code
Create a tracking issue before finalizing a workaround, version cap, or partial fix. Cite its number in the pull request and place the full URL beside the code.
05 / Hard prohibitions
No agent co-author trailer
Agents may not add themselves as co-authors. A separate pull-request field records the agent's name and version.
Source excerpt starting at line 210.210- NEVER add Co-Authored-By with yourself as co-author of the commit. Agents cannot be authors, humans can be, Agents are assistants.
06
Remote names checked rather than assumed
Before remote commands, run git remote -v. If the two expected names differ, report the mismatch and propose the exact rename commands.
07
A coverage target with an upper bound
Tests are to cover exactly what the PR changes: every changed behavior gets a test, every test must fail without the change, and tests for pre-existing logic or third-party functions are excluded.
Source excerpt starting at line 152.152- Target exactly 100% coverage of what the PR changes — no more, no less. Every changed or added behaviour must have a test; every test must fail without the PR's change. Do not add tests for pre-existing logic that was already present before the PR, and do not test standard-library or third-party functions. The exception is deliberate behaviour or integration tests, which may cross those boundaries by design.