Repository navigation
Contributing
CodingDude is developed with the same discipline it applies to your code: plan, test, gate, review, then ship. The repository's CONTRIBUTING.md is canonical; this page is the short version.
git clone https://github.com/cybersenses/codingdude.git
cd codingdude
uv syncPython 3.12+, uv, git. Node is needed only for the frontend.
gates.batRuns three things, and all three must be clean:
uv run ruff check src tests tools
uv run mypy
uv run pytest -qFrontend:
cd frontend && npm run lint && npm run test && npm run buildCI runs the same on windows-latest — pytest/lint/types, frontend
(lint, vitest, build), and the scripted benchmark. Python tooling is
venv-scoped: run through uv run, not a bare shell. Before declaring a tool
"missing", check .venv/Scripts/ — "not recognised" does not mean absent.
spec → ticket → tests → implement → gates → review → commit/push → roadmap
- Design first. Non-trivial work starts as a PRD and a tech design, then a roadmap item, then tickets. Each ticket is a tracer bullet: one demonstrable vertical slice with its blocking edges declared.
-
Tests at seams. The engine is tested with scripted
FunctionModelruns against temporary workdirs. Mock only true system boundaries (third-party APIs, time); prefer the real store over a mocked one. - Behavior changes ship with tests at pre-agreed seams.
- Gates before claims. Never say a change is complete without running the gate in that session and reading the output — cite the count and the exit code.
- Review, then push. A push requires a recorded two-axis review of the exact diff (Review Gate). Fixing a finding voids the record, which is what forces the fix to be reviewed.
- Track it. Close the ticket citing the commit that closed it; close the roadmap item when its tickets are closed, naming the evidence.
The short list; the repository's own conventions file is authoritative.
- Read the target area first. Reuse existing helpers over new ones — one source of truth per behaviour — and name what you reused.
- Match the existing style. Same naming, same structure, same vocabulary (CONTEXT.md).
- Fail fast. Guard clauses, early returns, flat logic. Deep nesting and very long functions are a smell — split with intent.
-
No silent catches. Every
excepthandles, logs with context, or propagates. At tool boundaries return readable messages; in core logic, raise. - Strict typing where the language supports it; validate external input at the boundary.
- No placeholders, no TODOs, no hardcoded secrets, no
eval. - Preserve line endings. This is a Windows-primary project with mixed history; a whole-file rewrite in a diff is usually a line-ending accident, not a change.
- Never cite your own branch SHA in tracked docs. It dangles after a squash-merge and breaks the next PR's CI.
tools/claim_check.py runs as part of the suite over the strict documentation
set. A stale file path, a line reference past the end of a file, an unknown commit
hash or a wrong line count fails pytest rather than waiting for a reviewer to
notice. If you change code that a document describes, the document is part of the
change.
- A new tool must honour workdir containment and go through the shared atomic-write helper.
- A new agent must take its caching from the capabilities seam
(
agent_caps.py) and its spend limits fromlimits.py; tests pin both, because a missing capability or limit is invisible at runtime. - Tool policy for a delegation function is registry-locked in code — that lock is the safety property, so it is not a config knob.
CodingDude is AGPL-3.0-or-later. Contributions are accepted under the CLA in CLA.md.
Third-party code and adapted skill libraries are recorded in NOTICE.md — add an entry when you bring work in.
- Discord — https://discord.gg/UA73mmfb for setup questions and design discussion.
- GitHub issues — reproducible bugs and feature requests.
- Security — never publicly; see SECURITY.md.
Start
How it works
Using it
Project