Terminal Ops

Guardrails

• inspect before editing
• stay read-only if the user asked for audit/review only
• prefer repo-local scripts and helpers over improvised ad hoc wrappers
• do not claim fixed until the proving command was rerun
• do not claim pushed unless the branch actually moved upstream

Workflow

1. Resolve the working surface

Settle:

• exact repo path
• branch
• local diff state
• requested mode:
  • inspect
  • fix
  • verify
  • push

2. Read the failing surface first

Before changing anything:

• inspect the error
• inspect the file or test
• inspect git state
• use any already-supplied logs or context before re-reading blindly

3. Keep the fix narrow

Solve one dominant failure at a time:

• use the smallest useful proving command first
• only escalate to a bigger build/test pass after the local failure is addressed
• if a command keeps failing with the same signature, stop broad retries and narrow scope

4. Report exact execution state

Use exact status words:

• inspected
• changed locally
• verified locally
• committed
• pushed
• blocked

Output Format

SURFACE
- repo
- branch
- requested mode

EVIDENCE
- failing command / diff / test

ACTION
- what changed

STATUS
- inspected / changed locally / verified locally / committed / pushed / blocked

Pitfalls

• do not work from stale memory when the live repo state can be read
• do not widen a narrow fix into repo-wide churn
• do not use destructive git commands
• do not ignore unrelated local work

Verification

• the response names the proving command or test
• git-related work names the repo path and branch
• any push claim includes the target branch and exact result