Chapter 8: Paperclip production rollout

Updated: 2026-06-08 · POC completion summary and next-session handoff for production Paperclip adoption.

Decision: the Paperclip proof of concept is complete enough to move from evaluation into a staged production rollout. Paperclip should become the primary local control plane for PM and Dev orchestration; Codex remains the coding executor; GitHub remains the durable source of truth; Telegram/OpenClaw becomes the intake and notification layer, not an unrestricted command runner.

What changed since Chapter 7

Chapter 7 recommended proving the execution layer before using Paperclip. That work has now happened. The supervised runner and watchdog passed self-test, failure-injection, status, and alert-suppression checks. Paperclip was then installed locally under guardrails, launched Codex successfully, completed PM-only and docs-only pilots, and produced a useful first real-work analysis on the SafetyGraphics modernization queue.

The recommendation therefore changes from "delay Paperclip until the runner is proven" to "roll Paperclip forward as the production control plane, while preserving the runner contracts, GitHub audit trail, and Telegram safety boundaries that made the POC reliable."

Proof completed

Area	Result	Evidence
Supervised runner	Passed.	P009 delivered runner ledger scaffold, watchdog failure tests, PM audit/docs PR flow, and allowlisted Telegram/OpenClaw runner actions. Main self-test, status, and check commands passed from Telegram.
Paperclip source/security gate	Passed with guardrails.	P008 #33 concluded conditional go: no install until local disposable/loopback-only constraints were accepted, telemetry disabled, no credentials, no OpenClaw auth, and no auto-pairing.
Local Paperclip install	Passed after unsandboxed retry.	Initial embedded PostgreSQL bootstrap failed in the sandbox on `shmget`. Direct local install worked under guardrails on `127.0.0.1:3100`.
PM-only pilot	Passed.	Paperclip task P008 #34 used a local Codex agent to audit loopback-only operation, absence of real credentials/OpenClaw auth, PM-only workflow suitability, and requirements before broader rollout.
Productionized local baseline	Passed.	Paperclip root is `/Users/obot/.openclaw/paperclip`; source commit `76c88e585513dd19bce916ad555a8fee42ff7ded`; service `local.obot.paperclip`; health endpoint returns OK on `http://127.0.0.1:3100/api/health`; telemetry remains disabled.
Codex runtime baseline	Passed.	Paperclip-launched Codex used `--sandbox workspace-write`, scoped network proxy access to `127.0.0.1`/`localhost`, and successfully reached the Paperclip loopback API from inside a run.
Docs-only Dev pilot	Passed.	CodexDocsDev created and merged docs-only PRs, then hardened its contract so successful runs post evidence and PATCH the Paperclip task to done without operator repair.
No-edit compliance	Passed.	A no-edit Paperclip/Codex task completed with no repository changes and a clean worktree.
Real-work pilot	Partially passed.	CodexSafetyDev produced useful P004 SafetyGraphics issue analysis after correction, but the first artifact landed as a PR when it should have been an issue comment. The PR was closed unmerged and the note was moved to the issue.

Current operating model

Component	Production role	Boundary
Paperclip	Local control plane for tasks, agents, state, run visibility, and eventually scheduling.	Keep loopback-only initially. Do not expose publicly. Remote access, if needed, should be reviewed separately.
Codex	Primary PM/Dev executor launched by Paperclip.	Use dedicated workdirs, explicit agent instructions, scoped network proxy, and repo-level task authority.
GitHub	Durable source of truth for issues, PRs, comments, review gates, and public evidence.	Merges remain human-gated. Analysis notes default to issue comments unless a repo artifact is explicitly requested.
Telegram/OpenClaw	Human front door and notification channel.	Map messages to allowlisted actions. Do not forward arbitrary chat text into command execution.
Supervised runner contracts	Fallback and safety pattern for liveness, status, and alerts.	Keep the run-record/status/watchdog discipline even as Paperclip becomes the control plane.

Target Paperclip org structure

Recommendation: start with a four-agent company: one COO orchestrator plus three focused direct reports. The Testing agent should be separate from Development from day one, even if its initial contract is basic, because it creates an independent acceptance gate before work is presented as ready.

Agent	Reports to	Primary responsibility	Initial authority
COO	Human board / Jeremy	Overall project movement. Receives Telegram/operator prompts, chooses the next workflow, coordinates PM/Dev/Test, monitors blocked work, and reports concise status back to the operator.	May create/assign Paperclip tasks, request scheduled runs, ask agents for clarification, and summarize results. Does not merge PRs or broaden scope without approval.
PM	COO	Maintains the queue. Reviews GitHub issues for clarity, compliance with the operating framework, acceptance criteria, sequencing, labels/status, and Paperclip/GitHub sync correctness.	May update Paperclip tasks and GitHub issue comments/metadata under the Obot account. Should default to issue comments for analysis and ask COO for scope decisions.
Development	COO	Implements approved work. Reads the GitHub/Paperclip task, asks the PM or COO for clarification when requirements are incomplete, writes code/docs, runs checks, and opens PRs.	May create branches and PRs in approved Obot repositories. Does not merge. Does not invent new requirements when issue acceptance criteria are unclear.
Testing	COO	Independently verifies Development output against the issue requirements and the project documentation framework. Produces acceptance notes, missing-test findings, or requested changes.	May inspect PRs, run available tests/checks, comment findings, and mark Paperclip verification tasks done/blocked. Does not modify implementation unless explicitly assigned a fix task.

This structure keeps the first production company small but real: the COO owns momentum, the PM owns issue quality and queue hygiene, Development owns implementation, and Testing owns acceptance evidence. Additional skills, tools, or specialist agents can be added later only when a repeated bottleneck is visible.

Daily operating loop

The COO runs once per day on schedule and may also be prompted manually through Telegram/OpenClaw.
The COO asks the PM to review the next candidate in the GitHub/Paperclip queue.
The PM confirms the issue is ready, updates GitHub/Paperclip metadata or comments, and either recommends Dev start or returns a clarification/blocker to the COO.
If the task is ready, the COO assigns Development a scoped Paperclip task linked to the GitHub issue.
Development implements the issue, opens a PR, posts evidence, and requests Testing review.
Testing verifies the PR against the issue requirements and posts an acceptance note or requested changes.
The COO summarizes the outcome to Telegram after durable GitHub/Paperclip artifacts exist.

The first scheduled version should run PM-only/no-edit. After that passes reliably, allow the COO to start Dev tasks for explicitly ready issues. Merge remains human-gated.

Lessons from the POC

Paperclip can run Codex for the intended use case. The gap is no longer "can it launch Codex?" The remaining work is production communication, scheduling, credential scope, and task policy.
Artifact placement needs a rule. Real-work analysis and triage should default to GitHub issue comments. Repository files and PRs should be created only when the task explicitly asks for durable repo content or code changes.
Disposition must be explicit. Agents must post evidence and update Paperclip task state themselves. The POC showed this can work reliably once it is written into the agent contract.
No-edit tasks are valuable acceptance tests. They prove the agent can inspect, reason, and report without mutating a repo.
Domain judgment still needs human gates. Paperclip/Codex can move the queue, but first-pass analysis can be too generic. SafetyGraphics and gsm work should keep explicit PM checkpoints around statistical claims, validation evidence, release readiness, and package scope.
Telegram is useful, but only as an allowlisted interface. It should trigger known Paperclip workflows, request status, and deliver concise summaries. It should not become a free-form shell or arbitrary Codex prompt transport.

Rollout phases

Phase 0 — Freeze and back up the POC baseline

Record the current Paperclip source commit, service name, health endpoint, data directory, and agent names.
Back up Paperclip configuration and local data before adding credentials or scheduling.
Preserve working launch/restart/health-check instructions for /Users/obot/.openclaw/paperclip.
Keep telemetry disabled and Paperclip bound to 127.0.0.1:3100.

Phase 1 — Version the local operating contracts

Create a controlled local location for agent instructions and task templates.
Create the initial Paperclip org: COO as orchestrator, with PM, Development, and Testing as direct reports.
Define the COO's Telegram-facing contract: accept operator intent, translate it into allowlisted Paperclip workflows, and report status only after artifacts exist.
Define canonical contracts for PM selection, Dev implementation, no-edit verification, issue-comment analysis, PR creation, and task disposition.
Define the initial handoff contracts: PM-to-Dev readiness note, Dev-to-Test review request, Test-to-COO acceptance or requested-changes note.
Adopt the artifact-placement rule: issue comment by default; PR only for requested repo changes.
Keep per-project agent instructions separate, starting with SafetyGraphics/gsm work.

Phase 2 — Add GitHub integration carefully

Evaluate Paperclip's GitHub Issues sync plugin path first, because the target model is direct Paperclip task tracking against GitHub issues.
Use the sequestered obot GitHub identity for this integration. In this deployment, Paperclip is Obot; it may act through Obot credentials inside the intentionally isolated Obot GitHub estate.
Start with GitHub issue sync for selected Obot repositories: import/link issues, mirror status where safe, and optionally bridge comments after a smoke test.
Keep local gh available for Codex implementation work such as branch, commit, push, and PR creation until the plugin proves it covers those workflows.
Grant enough permissions for the Obot estate workflow: read selected repositories, read/write issues and comments, create branches/PRs where approved. Treat merge/admin/secret/package permissions as separate escalation decisions.
Do not grant broad organization access, secret access, package publishing, Pages administration, or autonomous merge permissions.
Make every GitHub-writing workflow leave a durable issue comment or PR link.

Phase 3 — Add Telegram/OpenClaw control

Implement allowlisted Telegram actions against the COO: health, latest status, review next queue item, start approved task, check failures, summarize latest artifact, and stop/pause where supported.
Route normal operator prompts to the COO, not directly to PM/Development/Testing, so one agent owns project-level coordination and status.
Require task templates or explicit issue IDs for work creation. Do not pass arbitrary Telegram prose into --command or an unrestricted Paperclip task runner.
Send Telegram summaries only after the durable Paperclip/GitHub artifact exists.
Keep summaries short, plain text, and free of prompts, raw commands, transcripts, or credentials.

Phase 4 — Turn on scheduled autonomy

Begin with a daily COO-triggered PM queue review that is read-only/no-edit.
If the PM finds a safe candidate, the COO creates or updates the Paperclip task and notifies Telegram instead of immediately launching broad Dev work.
Promote to scheduled Dev only after daily PM queue review, GitHub/Paperclip sync, and no-edit runs are stable.
Once promoted, the daily sequence is COO → PM readiness → Development PR → Testing acceptance → COO summary.
Measure autonomy by useful issue comments, reviewable PRs, and low operator repair rate, not by number of agent runs.

Phase 5 — Apply to representative project work

Continue P004 SafetyGraphics sequencing first, because the real-work pilot already created useful issue-level analysis there.
Use P005/gsm.safety only after the P004 implementation, validation, and testing decisions are clearer.
Keep statistical validation, visual regression evidence, accessibility checks, and release-readiness decisions behind explicit review gates.
Use Paperclip to drive momentum: select next issue, draft implementation plan, open PR, summarize review blockers, and prepare next task.

Production go/no-go gates

Gate	Pass condition
Health and restart	Paperclip starts cleanly, health endpoint is OK, and restart steps are documented.
Backup and recovery	Configuration and task data can be backed up and restored or recreated without guesswork.
Loopback/security posture	Paperclip remains loopback-only unless a separate remote-access design is approved.
Task disposition	Agents post evidence and mark tasks done/blocked/failed without operator repair.
No-edit compliance	No-edit verification tasks leave target repos clean.
Artifact placement	Analysis notes go to issue comments; PRs contain only intentional repo changes.
Org handoff	COO, PM, Development, and Testing roles exist with explicit handoff contracts and no direct Telegram-to-Dev bypass.
GitHub permissions	Any token/App is limited, documented, auditable, and merge-incapable.
Telegram safety	Telegram triggers only allowlisted Paperclip actions and never forwards arbitrary text as executable command input.

Known risks

Prompt drift: agents may create plausible but misplaced artifacts unless the task template is explicit.
Credential creep: GitHub integration can become too broad if convenience wins over scoped access.
Scheduling reliability: Paperclip scheduling has not yet been proven across multiple days of unattended operation.
Multi-agent handoff: single-agent PM/Dev tasks passed; the COO → PM → Development → Testing workflow still needs production proof.
Browser/runtime checks: some visual or Playwright-style checks may still require host-specific handling outside the sandbox.
Domain correctness: safetyGraphics/gsm work needs human review for statistical, regulatory, and package-release decisions.

Do not do

Do not expose Paperclip publicly as the next step.
Do not add a broad GitHub token or organization-wide credential.
Do not let Telegram free text execute as a command or unrestricted agent prompt.
Do not allow autonomous merges.
Do not turn issue-analysis notes into repository files by default.
Do not restart the framework selection debate unless a production rollout gate fails.

Next-session handoff

Starting point: assume the POC is complete and Paperclip is the selected production control plane. The next session should implement the rollout, not re-evaluate frameworks.

Create a production Paperclip rollout issue/task that references this chapter as the operating plan.
Back up the current Paperclip install, data, service configuration, and agent instructions.
Move or copy agent instructions and task templates into a controlled local configuration location.
Create the initial org: COO orchestrator with PM, Development, and Testing direct reports.
Evaluate and configure GitHub Issues sync for selected Obot repositories using the sequestered Obot GitHub identity.
Implement allowlisted Telegram/OpenClaw commands that address the COO for Paperclip health, status, queue review, approved task start, failure check, and latest-artifact summary.
Add the first scheduled COO → PM queue review as read-only/no-edit.
Run one scheduled representative P004/P005 analysis task and require the artifact to land as a GitHub issue comment unless a PR is explicitly requested.
After the PM-only schedule passes, run one full COO → PM → Development → Testing pilot against a small ready issue, with merge held for human approval.

Decisions Jeremy still owns

Whether GitHub sync starts with the external Paperclip GitHub Issues plugin, a local custom bridge, or local gh passthrough while the plugin is evaluated.
Whether Paperclip stays loopback-only for production v1 or gets a separate Tailscale/remote-access design.
Which project queue runs first under schedule. Recommended: continue P004 SafetyGraphics before P005/gsm.safety.
Which actions, if any, can advance from "notify for approval" to "start automatically" after the first week of scheduled runs.