Policy in code
Keep command policy and approval checks deterministic. The model proposes work but does not authorize itself.
The alternative. A natural-language safety prompt is easier to add, but it cannot establish an execution boundary.
MAINFRAME
On its protected Pi shell routes, MAINFRAME checks proposed commands against policy and pauses approval-bound work for a person's decision. Checkpoints and status help make the work reviewable.
My contribution
- Develop deterministic command classification and approval boundaries for protected Pi shell routes.
- Expose readiness checks so installation and actual enforcement remain distinct.
- Keep selected checkpoints and bounded execution receipts for inspection and handoff.
The problem
A coding agent can propose useful shell work and destructive shell work through the same interface. MAINFRAME makes that boundary inspectable and keeps permission decisions outside the model.
Working constraints
- Support Pi's existing shell workflow instead of replacing the editor or agent harness.
- Keep command classification deterministic and require a person for exact approvals.
- Report the running host's readiness because installation alone does not prove enforcement.
What connects
to what.
The workflow below follows the main handoffs and the boundaries each one introduces.
Workflow outline
Request
Pi proposes a shell command or an allowlisted function call.
Policy
The package normalizes and classifies the request before any protected execution route runs.
Authority
Blocked work is refused. Approval-bound work pauses for a person's exact decision.
Evidence
Bounded receipts and explicit checkpoints support inspection and later handoff.
The decisions
Readiness with evidence
Separate installed, configured and locally verified states for the running Pi environment.
The alternative. A single protected badge would be simpler and would overstate support on unverified routes.
Explicit memory
Store selected checkpoints, discoveries and progress instead of assuming a later session has the conversation.
The alternative. Replaying entire transcripts creates more noise and a larger privacy surface.
After the
happy path.
These are the failure cases and maintenance responsibilities that shape the implementation:
- Review policy changes alongside regression fixtures.
- Check doctor output against the actual Pi package and host configuration.
- Keep receipts and memory local, and never treat them as permission for a new action.
What the work enables.
- A Pi user can inspect command policy, keep explicit project checkpoints and check which protections are ready on the current host.
- The package documents where its shell boundary applies and where Pi or the operating system remains responsible.
Follow the evidence
- Read the public source
The repository contains the Pi package, shell policy, checkpoints, tests and readiness contracts.
- Read the Pi package guide
The README states the active Pi scope and the boundary's explicit limitations.
Want to discuss the details? Let’s talk ↗