Developer tooling / Active build
Project Steward
AI-assisted development can lose intent, decisions, evidence, and review context across turns. Project Steward gives that work a local record system instead of treating chat output as project memory.
I built a TypeScript and Node.js CLI that models turn records, claims, evidence, reviewer results, synthesis, and steward decisions while keeping model output advisory by default.
Evidence workflow
Project Steward
AI-assisted project work becomes durable, reviewable records.
- Role
- Sole developer
- Focus
- Developer tooling and AI workflow systems
- Maturity
- Active build
- Access
- Local-only
- Technologies
- TypeScript
- Node.js
- OpenAI API
- Last reviewed
- Jul 2026
The problem
What the project had to handle
The main constraint is deciding when advisory model output is allowed to become durable project state. A model can help review, summarise, or produce a result, but durable project records should change only through explicit evidence and decisions.
Project Steward is local-only developer tooling. It is not a public service, automatic audit product, or external compliance system.
Key decisions
The shape of the build
Model work as records
Turns, claims, evidence, reviewer results, synthesis, and decisions are represented as local project records.
That makes AI-assisted work inspectable later instead of depending on a conversation transcript.
Gate model review
The OpenAI reviewer path requires explicit confirmation, provider checks, and recorded provider output.
A reviewer result can inform the work without silently becoming a decision or memory update.
Make memory changes explicit
Project memory changes happen through recorded decisions rather than automatic model mutation.
The system preserves a boundary between helpful generated text and validated project state.
How it works
End-to-end flow
The CLI records project work as events and domain records. When the guarded reviewer path is invoked, it checks provider settings, reads credentials only after confirmation, sends one reviewer request, and stores the provider result for later review.
01
Record the work
Turns, claims, evidence, and project events are stored as local records.
02
Run review through a gate
Provider calls require explicit confirmation and produce inspectable reviewer output.
03
Promote only by decision
Memory and project records change through explicit decisions rather than automatic model output.
What I implemented
The working surface
CLI and domain model
- Implemented a local TypeScript CLI for project-governance workflows.
- Modelled turn records, claims, evidence, reviewer results, synthesis, and decisions.
- Stored project records locally rather than relying on chat context.
Guarded reviewer path
- Added explicit confirmation before model review runs.
- Checked provider settings before reading the API key.
- Recorded reviewer results as provider output, not final decisions.
Memory and decisions
- Kept generated output advisory by default.
- Separated reviewer output from durable memory changes.
- Preserved prompts, evidence, and decisions as inspectable records.
Validation
Checks and evidence
Local presentation checks passed
Local presentation checks passed for the case-study surface.
Repository checks passed
The project passes `make doctor`, `make check`, and Finch verification for the scoped project surface.
Guarded reviewer path implemented
The implementation includes an explicit single-reviewer provider path with confirmation and audit records.
Local-only boundary
The project is represented as local CLI tooling, not as a hosted service or automatic auditing product.
Current state
Local-first active build focused on durable project records and guarded model review.
Model output remains advisory; project records change through evidence and explicit decisions.
Provider result-quality evaluation remains separate from the implemented record and review workflow.