fable-agent/docs/pi-integration.md

Pi Integration

Thesis

Pi makes agents act.
fable-agent proves what happened.
git-proxy deploys through 8099/deploy.

Pi is the minimalist harness: loop, tools, TUI, branching, hot reload, and human-steered iteration. fable-agent is the proof layer: typed attestations, safety scanners, risk gates, and guarded deploy receipts.

Command contract

After Pi, Codex, Claude Code, OpenClaw, or another harness changes code, run:

fable-agent verify . --out .fable/attestations/latest.json

Factory-aware alias:

fable-agent factory verify . --out .fable/attestations/factory-latest.json

A harness may only claim done when it has either:

1. attached an attestation with verification_status and residual risk, or
2. said UNVERIFIED clearly.

Attestation fields that matter

{
  "schema": "fable.verification.attestation.v1",
  "verification_status": "verified|partial|failed|unverified",
  "risk_findings": [],
  "human_review": { "required": false, "reasons": [] },
  "deploy_route": "8099/deploy via git-proxy",
  "unverified_claims": []
}

Pi prompt snippet

Before you say done, run:

fable-agent verify . --out .fable/attestations/latest.json

Summarize verification_status, human_review.required, risk_findings, and unverified_claims.
If you cannot run it, say UNVERIFIED and explain why.

Verified vs memory

• Current guarded deploy path for fable-agent decisions: 8099/deploy via git-proxy.
• 8098 deploy-webhook exists, but direct use is legacy/stale for fable-agent decisions.
• Factory inventory, RSI cron, and container counts may come from memory; live receipts are stronger.
• rsi_canary degraded→patched→recovered is proven by receipt.
• Non-canary degraded repair is not proven until a degraded-skill recovery receipt exists.

What not to build

• Pi clone
• new orchestrator
• dashboard
• marketplace
• generic self-healing claims
• direct 8098 deploy assumptions