← All work

OPEN SOURCE / DEVELOPER TOOLS

Open-Ready.
Build privately. Share deliberately.

A local-first, Git-native tool for developing personal software with AI coding agents and preparing a reviewable public release without delegating the publication decision.

OPEN SOURCE / MITPYTHON 3.12+ / GITEARLY RELEASE / v0.1.0-p0
PRODUCT

Private-first developer tooling

MY ROLE

Problem framing, design direction, agent coordination and review

THE QUESTION

How can a private project become shareable without exposing what should stay private?

Conceptual architecture, not a live execution trace or proof of security.

01 / THE PROBLEM

Private work should stay private.

AI coding agents make it easier to create and modify software, but they also increase the importance of knowing what is being committed, tested and eventually distributed. Personal data, machine-specific paths, credentials and repository history are not automatically appropriate for a public release.

I wanted to build useful software for myself first, without having to choose in advance whether each project would become open source.

02 / MY CONTRIBUTION

Define the boundary, then test it.

I shaped the problem, operating requirements, architecture and release decisions, and directed AI-assisted implementation and adversarial review. AI tools performed much of the code reading and implementation. My role centered on the requirements, system behavior, evaluation and decisions that should remain human-controlled.

03 / THE ARCHITECTURE

A small local tool, not a hosted platform.

Open-Ready uses Python 3.12+ and Git, with no frontend framework or hosted account required. The command-line interface scaffolds private projects, runs checks, supports backups, examines provenance and prepares candidates for separate review.

There is no publication command in the regular developer CLI. That is an intentional boundary in the tool's interface, but not a substitute for restricting the agent's own host credentials.

04 / HOW IT WORKS

Prepare evidence before a decision.

01 / Develop privately

Start with a private scaffold and personal runtime data outside the source tree.

02 / Examine the candidate

Review known secret patterns, paths, Git objects, dependencies and required decisions.

03 / Verify the exact bytes

Recompute the content digest and issue a review packet without authorizing publication.

For installation and reproducible commands, use the maintained Open-Ready source repository.

05 / EVIDENCE

Measured checks, bounded claims.

The first public release includes a unit suite, acceptance scenarios, a documented verification process and a GitHub Actions check workflow. The v0.1.0-p0 release notes record what was measured and the remaining limitations. Those results apply to that revision, not automatically to every later environment or project.

Browse the code and documentation ↗

06 / LIMITATIONS & NEXT

Safety is a process, not a label.

Pattern-based scanning cannot establish that arbitrary personal prose is absent. The early release was measured primarily on Linux/WSL2. Git hooks can be bypassed, and an agent with repository administration credentials can still publish outside this tool. Proper credential separation is an operator responsibility.

Open-Ready remains early-stage software. Its public issues document unresolved problems. The project is MIT licensed and open to reviewed contributions.