|
| 1 | +## Repo Info |
| 2 | + |
| 3 | +- **Package**: `serializable` — base class with serialization helpers for user-defined Python objects. |
| 4 | +- **GitHub**: https://github.com/openvax/serializable |
| 5 | +- **PyPI**: https://pypi.org/project/serializable/ |
| 6 | +- **Author**: Alex Rubinsteyn <alex.rubinsteyn@unc.edu> |
| 7 | +- **Primary branch**: `master` |
| 8 | + |
| 9 | +--- |
| 10 | + |
| 11 | +## Golden Rules |
| 12 | + |
| 13 | +1. **Never commit to `master`.** Always `git checkout -b <feature-branch>` before editing. Land via PR. |
| 14 | +2. **Every PR bumps the version.** Even doc-only PRs — at minimum a patch bump. Edit `serializable/version.py`. |
| 15 | +3. **"Done" means merged AND deployed to PyPI** — never stop at merge. After a PR merges, run `./deploy.sh` from a clean `master`. Skipping deploy = task not done. |
| 16 | +4. **File problems as issues, don't silently work around them.** If you hit a bug here or in a sibling openvax repo, open a GitHub issue on the correct repo and link it from the PR. |
| 17 | +5. **After a PR ships, look for the next block of work.** Read open issues across relevant openvax repos, group by dependency + urgency. Prefer *foundational* changes that unblock multiple downstream improvements; otherwise chain the smallest independent improvements. |
| 18 | + |
| 19 | +--- |
| 20 | + |
| 21 | +## Before Completing Any Task |
| 22 | + |
| 23 | +Before considering any code change complete, you MUST: |
| 24 | + |
| 25 | +1. **Run `./format.sh`** — Auto-format all code |
| 26 | +2. **Run `./lint.sh`** — Verify linting passes (runs both `ruff check` and `ruff format --check`) |
| 27 | +3. **Run `./test.sh`** — Verify all tests pass |
| 28 | + |
| 29 | +Do not tell the user you are "done" or that changes are "complete" until all three of these pass. |
| 30 | + |
| 31 | +## Scripts |
| 32 | + |
| 33 | +- `./format.sh` — Formats code with ruff (run this first) |
| 34 | +- `./lint.sh` — Checks linting and formatting (must pass). **Always use this for linting if it exists.** |
| 35 | +- `./test.sh` — Runs pytest with coverage (must pass) |
| 36 | +- `./deploy.sh` — Builds the distribution and uploads to PyPI via `twine` (gates on `lint.sh` and `test.sh`). **Always use this for deploying if it exists.** |
| 37 | +- `./develop.sh` — Installs package in development mode into `.venv` |
| 38 | + |
| 39 | +## Code Style |
| 40 | + |
| 41 | +- Use ruff for formatting and linting |
| 42 | +- Configuration is in `pyproject.toml` under `[tool.ruff]` |
| 43 | +- Line length: 100 characters |
| 44 | +- Target Python version: 3.9+ |
| 45 | + |
| 46 | +--- |
| 47 | + |
| 48 | +## Workflow Orchestration |
| 49 | + |
| 50 | +### 1. Upfront Planning |
| 51 | +- For ANY non-trivial task (3+ steps or architectural decisions): write a detailed spec before touching code |
| 52 | +- If something goes sideways, STOP and re-plan immediately — don't keep pushing |
| 53 | +- Use planning/verification steps, not just building |
| 54 | +- Write detailed specs upfront to reduce ambiguity |
| 55 | + |
| 56 | +### 2. Self-Improvement Loop |
| 57 | +- After ANY correction from the user: update `tasks/lessons.md` with the pattern |
| 58 | +- Write rules for yourself that prevent the same mistake |
| 59 | +- Ruthlessly iterate on these lessons until mistake rate drops |
| 60 | +- Review lessons at session start for relevant project |
| 61 | + |
| 62 | +### 3. Verification Before Done |
| 63 | +- Never mark a task complete without proving it works |
| 64 | +- Diff behavior between the latest code and your changes when relevant |
| 65 | +- Ask yourself: "Would a staff engineer approve this?" |
| 66 | +- Run tests, check logs, demonstrate correctness |
| 67 | + |
| 68 | +### 4. Demand Elegance (Balanced) |
| 69 | +- For non-trivial changes: pause and ask "is there a more elegant way?" |
| 70 | +- If a fix feels hacky: "Knowing everything I know now, implement the elegant solution" |
| 71 | +- Skip this for simple, obvious fixes — don't over-engineer |
| 72 | +- Challenge your own work before presenting it |
| 73 | + |
| 74 | +### 5. Autonomous Bug Fixing |
| 75 | +- When given a bug report: just fix it. Don't ask for hand-holding |
| 76 | +- Point at logs, errors, failing tests — then resolve them |
| 77 | +- Zero context switching required from the user |
| 78 | +- Fix failing unit tests without being told how |
| 79 | + |
| 80 | +--- |
| 81 | + |
| 82 | +## Task Management |
| 83 | + |
| 84 | +1. **Plan First**: Write plan to `tasks/todo.md` with checkable items |
| 85 | +2. **Verify Plan**: Check in before starting implementation |
| 86 | +3. **Track Progress**: Mark items complete as you go |
| 87 | +4. **Explain Changes**: High-level summary at each step |
| 88 | +5. **Document Results**: Add review section to `tasks/todo.md` |
| 89 | +6. **Capture Lessons**: Update `tasks/lessons.md` after corrections |
| 90 | + |
| 91 | +--- |
| 92 | + |
| 93 | +## Core Principles |
| 94 | + |
| 95 | +- **Simplicity First**: Make every change as simple as possible. Impact minimal code. |
| 96 | +- **No Laziness**: Find root causes. No temporary fixes. Senior developer standards. |
| 97 | +- **Minimal Impact**: Changes should only touch what's necessary. Avoid introducing bugs. |
0 commit comments