Building small, reviewable, and security-conscious software experiments.
I am learning professional GitHub workflows by using them on real, deliberately small systems. My current focus is the intersection of GitHub, Python, and human-supervised AI.
I prefer evidence over long skill lists: an issue that defines the problem, a small pull request, tests that protect the behavior, and a written decision that explains the trade-off.
- professional Git and GitHub workflows: issues, Projects, branches, pull requests, CI, and review;
- Python applications with explicit data models and offline tests;
- AI features where the model recommends and a human remains accountable;
- security gates that separate “technically complete” from “safe to publish.”
See NOW.md for the work currently in focus.
- Start private when the data, licenses, or security boundary are not yet proven.
- Define the problem and the non-goals before adding features.
- Keep changes small enough to review and reverse.
- Never store secrets in source code or Git history.
- Test representative failures, not only the happy path.
- Treat AI output as untrusted advice until a human reviews it.
- Publish a learning claim only with evidence.
The longer version lives in WORKING-PRINCIPLES.md.
This profile is the first layer of a small public operating system for my work:
| Area | Purpose |
|---|---|
| Now | What I am actively learning and building |
| Working principles | How I make and review changes |
| Public Safety Gate | What must be true before work becomes public |
| Proof of Work | Claims connected to concrete evidence |
The system is intentionally compact. Public repositories should be useful, maintained, and safe—not a mirror of every unfinished experiment.
The first reviewed public artifact is Craft Playbook, an evidence-led guide to safe GitHub and human-supervised AI workflows. Other active experiments remain private while their safety gates are incomplete. The evidence catalog is maintained in PROOF-OF-WORK.md.
Last reviewed: 2026-08-29.