Pimpo
Documentation

Status#

What is built, what each phase gate needs, and which gates wait on people or time rather than code. Every "automated" gate runs in make check or make e2e on each commit.

PhaseBuiltGateGate status
F0 Foundation and compiler proofRuntime, compiler, event log, vault, server, UI shell≥ 8/10 recorded tasks compile on the first attempt and pass a holdoutPassed: 8/10 (proof)
F1 The compiled routineiCal, IMAP, HTTP and Telegram connectors; exploration over MCP; scheduler; judgments (Jev, LLM, Ollama); daily budget; owner channel; UI with real data30 consecutive daily runs of the morning brief, ≥ 29 successful, ≤ $0.01 per run, every failure alerted within 5 minutesWaiting on time: needs 30 days of real use. The live test with Claude passes (go test -tags live -run Live ./internal/app)
F2 Secure by constructionRules engine, approvals that pause the run, reversible forms, undo, receipts, repairs that keep old tests, cost view200-email scenario stopped and reversible; 50 injections leak nothing; runaway loop stops within budgetPassed, automated (go test -run Gate ./internal/app)
F3 The UI that tells the storyDemo mode, first-run guide, compile moment, decisions shown in explorations, version diffs, palette, PWA, WCAG AA palette4 of 5 new users finish four tasks unaided, each in under 10 minutesWaiting on people: usability sessions. The four tasks pass as browser tests, plus WCAG AA on every screen in both themes
F4 Three perfect usesEmail triage (drafts, archive, trash, unsubscribe), versioned memory, snapshots and safe upgrades, local judge (Qwen3-0.6B + LoRA on MLX) with a cascade to Jev30 days of the three routines at ≥ 97% success and < 2% undoneWaiting on time. Judge: 51% → 85% tuned, 92% with the cascade at 22% escalation (results)
F5 Install and migrate → v1.0Desktop app (Tauri, menu bar, sidecar, starts at login), one-line installer with checksums and systemd, goreleaser for Linux/macOS/Windows/RPi, CI matrix, OpenClaw and Hermes migration with a report per skill, Google sign-in3 non-technical people install in ≤ 15 min; 3 real installs migrate with ≥ 80% of skills workingWaiting on people (and on the end of the stand-by). Installer, migration and bundles are tested; the macOS DMG builds
F6 Memory with provenance, family, WhatsAppProvenance and trust on every fact, people with roles and responsible persons, per-person memory, accounts and chats, per-person rules, WhatsApp Cloud API with signed webhooks50 memory poisoning attacks 100% blocked; isolation tests 100%Passed, automated (TestGatePoisonedMemoryNeverBecomesInstruction, TestGateFamilyIsolation)
F7 GalleryEd25519-signed, content-addressed routines; audit run with every capability reachable; revocation; install review; publishing; 10 starter routines shipped in the binary50 community routines with zero divergences; confirmed reports removed within 72 hWaiting on community. The verifier runs on every index in CI and on every install
F8 More channels and connectorsConnector catalog (RSS, GitHub, Todoist, Notion, Obsidian, Home Assistant, Slack, Discord), external connectors over MCP with contracts (installed from a zip or folder, no restart), voice notes (whisper.cpp), email channel, generic channel API15 connectors with green contract tests against the real APIs for 4 consecutive weeksWaiting on time: 15 connectors exist with contract tests against fake servers; live probes (Testar) need 4 weeks of real credentials
F9 Small businessRemoved from the roadmap (2026-09-25): a back office is a different product and blurred what Pimpo is for. Photos read with Tesseract stay, as a channel feature——
F10 Native appsDesktop notifications, per-device pairing tokens with revocation, iOS and Android companion (Tauri) built from the same project, phone-first navigationMedian alert-to-tap < 3 s over 20 approvals; pairing and revocation pass on iOS, Android, macOS, Windows, LinuxPartly automated: pairing and revocation tests pass; the iOS app runs in the simulator; the Android APK builds but was not run (the local system image is incomplete); timing needs real devices
F11 Protection network and GuardSigned protection list (domains, skills, patterns), daily refresh, starter list in the binary, local override of false positives; Guard plugins for OpenClaw (before_tool_call) and Hermes (pre_tool_call)100 installs using the list; ≥ 1 real block from it; < 5% contested; Guard contract tests on the two latest versions of each agentWaiting on community. Guard suites pass against a real Pimpo (TestGuardPluginsAgainstPimpo); testing against real OpenClaw and Hermes releases is pending
F12 LongevityStable extension SDK (connectors, channels, judges, Guard, gallery, protection), Portuguese and English UI, security policy and threat model with a test per defense, LTS policy, governance, RFC process, code of conduct, user guide3 maintainers besides the founder; a published independent audit; LTS fixes within 7 daysWaiting on people. govulncheck: no reachable vulnerabilities (toolchain go1.26.8)

Everywhere#

Export, import and extension#

After the roadmap: closing the gaps with OpenClaw#

Ordered by Jev (tools/jev/decisions_gaps.py), all built and tested:

  1. Connectors from the MCP registry or by command or URL, with each tool's risk reviewed before installing (stdio and streamable HTTP).
  2. Run history of all routines, and schedules every 5 to 30 minutes.
  3. Memory organized every night (question and threshold calibrated with Jev) and searched by meaning.
  4. Chat in the app: changes are rehearsed, then confirmed exactly as shown.
  5. Assistants: named roles limited to their tools by the host.
  6. Help that reads the user guide, notification settings by kind, and Labs.
  7. Voice: dictation in the chat and answers read aloud.
  8. Web search with Brave or SearXNG.
  9. Channels: Discord, Slack and Signal, besides Telegram and WhatsApp.
  10. Models: Anthropic, OpenAI, OpenRouter or Ollama per job, each with its price for the budget.
  11. Cloud backups to S3-compatible storage or Google Drive, encrypted before upload.

Checked only against fake servers so far (they need the owner's accounts): Brave and SearXNG, Discord, Slack, signal-cli, the model APIs, S3 and Google Drive. The MCP registry search was checked live.

Next: what users of other agents miss most#

Ordered by Jev (tools/jev/decisions_next.py) from complaints about Hermes and OpenClaw:

  1. Routines that react to something new (a watched read, polled without a model). Built.
  2. A writing step in routines: a small model writes one text per item, bounded and billed. Built.
  3. An alert when a channel stops working, sent on the others and again when it comes back. Built.
  4. Going back after an update: the copy made before each update, like the daily ones, can be put back from Settings › Backup, and the owner is told after an update. It restores data, not the old binary (there is no auto-updater to roll back). Built.
  5. Prompt caching with Anthropic's API: system prompt, tools and the growing conversation are cached; cache writes and reads are priced in the budget. Checked against a fake server; needs an owner's API key to check live.
  6. Desktop as a client of a remote Pimpo: the menu bar switches between the local server and one elsewhere, paired with the phone's link; the local server stops meanwhile. The connection page was checked in the browser against a real server with the native calls stood in for; the native switch itself was built but not clicked through, since the owner's app was running.
  7. iMessage: cut (needs full disk access to read Messages).

Pimpo#

Renamed from Zodim (after Vigia) to Pimpo, the owner's tuxedo cat, with a black-and-white identity: the app icon, tray silhouette, favicon and logo are the cat's head, and the interface's accent is black on light and white on dark (color is kept only where it carries meaning). Existing installs carry over: ~/.zodim moves to ~/.pimpo, the keychain key is copied, old backups (including their secrets, which the first rename missed) and the old Drive folder still work, zodim <code> still pairs, the phone keeps its saved link, and a Tailscale node that already existed keeps its name so paired phones keep their link. The mascot lives in the app and, in the desktop app, optionally on the desktop in a small always-on-top window.

Complex routines, Pimpo's way#

Asked for after comparing with OpenClaw and Hermes skills (folders of scripts run by the agent), built without running arbitrary code:

  1. State between runs (state.get/set, 64 KB, saved only when a run succeeds), tested with state/expect_state in scenarios. Checked live: Claude compiled "only if the dollar went up" into a stateful routine on the first attempt.
  2. Routines in a repository: one folder per routine, export with a local commit, push on click, pull fast-forward only, every change checked (tests, audit, capability diff) and applied only by the owner. Tested end to end with real git repositories.
  3. Routines using routines (routines.run, manifest.uses): the caller must declare everything the helper touches, three levels at most, no loops, helpers' state read-only. Checked live: Claude reused an installed routine when asked.

From the OpenClaw documentation (2026-09-27)#

Ranked with Jev (tools/jev/decisions_openclaw_docs.py), then ordered by user value and dependencies, since the formula penalises table stakes: model setup redone (detection of Claude Code, Ollama and LM Studio; eleven providers; prices from OpenRouter's public catalog, never guessed; test before use), fallback models per job, spending by model and job, one conversation per chat channel with typing indicators, and a check-up that tests every part for real. Left out on purpose: a browser tool (against Pimpo's safety model; an MCP browser server can be added), group chats, a Codex backend, and auto-update (waits on the owner's signing and publishing decisions).

Languages#

The app, server messages (channels, approvals, notices), built-in connector texts, routine dates and money, and the phone/desktop shell page are in ten languages: pt, en, es, fr, de, it, ja, zh, ko, ru, with each language's plural rules. Portuguese is the source; the translations were written by a model and checked for keys, {slots} and plural forms, not reviewed by native speakers yet. Texts speak about Pimpo in the third person; first person is kept only for the owner's own words (example requests, preset rules). The user guide is English only.

Roadmap to v1.0 (docs/ROADMAP.md)#

ItemStatus
1.1 Known bugsDone (2026-09-29): 12 bugs fixed with tests, including the liberal level letting irreversible actions through.
1.3 Real-account validationTooling built (2026-09-29): pimpo report and GET /api/report measure runs, failures, silent failures, late runs, time Pimpo was off (a heartbeat records it from now on), repairs, approvals and cost; Validating on real accounts says how. On the owner's own data for 14 days: 30 runs, 4 failed, 0 silent. Waiting on time and people: three households for three weeks.
2.1 Auto-update with rollbackBuilt (2026-09-29): the desktop app checks the stable or beta channel at start and every six hours, installs signed updates and goes back to the previous version with the data as it was (restoring the pre-update snapshot); pimpo update and --rollback for servers. The signed macOS bundle was built and signed locally. Waiting on the owner: the two TAURI_SIGNING_PRIVATE_KEY secrets in the repository.
2.2 Official signingReady, waiting on the owner: the workflow signs and notarizes macOS with the APPLE_* secrets and signs Windows installers with WINDOWS_CERTIFICATE; both need accounts only the owner can open (Releases and support).
2.3 Docker and a server installBuilt (2026-09-29): multi-arch image (non-root, /data volume, health check) published to ghcr.io by release and on main, compose.yaml, Running on a server. Built and run locally: healthy, same login after restart, pimpo report inside.
2.4 PackagesReady, waiting on the owner: a Homebrew cask for the command line (GoReleaser) and one for the desktop app (scripts/cask.py), published to turbine-dev/homebrew-tap with HOMEBREW_TAP_TOKEN; winget updates with WINGET_TOKEN after a first manual submission; a Flatpak manifest and metainfo, not built yet (needs Linux). See packaging/.
2.5 WebsiteBuilt (2026-09-29): site/, published by pages.yml, with downloads for the visitor's system from the latest release. Waiting on the owner: Pages set to GitHub Actions, a domain (site/CNAME), and a demo video.
3.3 ProactivityBuilt (2026-09-29): a daily round of at most two routine suggestions from metadata only, accepted into an ordinary exploration, declined ones never repeated, backing off to Mondays; counted in pimpo report. Waiting on time: the acceptance rate in real use.
3.1 Gallery and protection listGallery built (2026-09-29): 51 signed, audited routines with tests (from 11): the 20 that passed the OpenClaw proof and 20 new ones, each imported with its tests and the audit. Waiting on the owner: creating the pimpo-gallery and pimpo-protection repositories.
3.2 SKILL.md skillsBuilt (2026-09-29): install from GitHub or a zip, review, grant capabilities (none means none); the agent loads a skill when a task matches and is then limited to its capabilities; scripts never run; the protection list refuses known skills; tested with Anthropic's public internal-comms skill. Waits on 4.2 for skills that need their scripts.
4.1 Agent-driven browserBuilt (2026-09-29, Labs, off by default): browser.open/read/follow/type/choose/click on Pimpo's own Chrome profile, scoped by host, clicks irreversible, passwords never typed, a window to sign in to sites (RFC 0002); tested with real Chrome against a local site. Waiting on use: the ten real sites of the roadmap's measure.
4.2 Code sandboxBuilt (2026-09-29, Labs, off by default): code.run in a Docker container with no network, read-only root, no capabilities, an unprivileged user, no environment and limits (RFC 0001). The isolation flags are tested on every build. Waiting on the owner: the live test pulls official images (alpine, python) and runs with PIMPO_SANDBOX_LIVE=1; a network allowlist and an SSH backend are follow-ups.
4.3 Learning the ownerBuilt (2026-09-29, on by default, off in Settings): a weekly round learns up to five preferences from the owner's own requests and decisions only, into memory as learned with the evidence; confirmed or removed in Memory, removed ones never relearned; $0.03 a round at most. Waiting on time: how many learned preferences owners keep.
5.1 Stable formatsBuilt (2026-09-29): Data formats freezes the database (user_version 1, a newer one is refused), routine, connector, memory and backup formats; internal/compat opens data written by the version that froze each format on every build. Waiting on the owner: tagging v1.0, which starts the first LTS line.
5.2 The phone as part of the agentBuilt (2026-09-29): Phone on the paired phone shares location, camera and shortcuts, each turned on on the phone; places with a radius or by name; arriving and leaving while the app is open or from iOS Shortcuts and Tasker with a key that only reports events; photos read on the computer; routines watch phone.arrivals, phone.photos and phone.shortcuts and run as soon as the phone reports. Tested end to end: a routine runs on arriving home and another on a photo of a bill. Waiting on the owner: a build of the phone app with the new camera and location permissions; background location without an automation needs a native plugin (a follow-up).
5.3 Voice conversationBuilt (2026-09-29): Talk in the chat, on desktop and phone: the wake word ("Pimpo") and every utterance are transcribed by Whisper on the owner's Pimpo, voice activity detection ends turns, answers are read with the chat's voice, talking interrupts them, follow-ups need no wake word for 12 s; actions are never approved by voice. Waiting on use: tuning the thresholds in noisy rooms; a wake word while the app is closed needs a native keyword spotter (a follow-up).
5.4 Parallel agents and long tasksBuilt (2026-09-29): Jobs plans a job into up to eight parts, each with only the capabilities it needs; the owner reviews the plan and starts it with a budget; parts run three at a time in the background (up to 90 minutes and 80 turns each), are saved after every step and resumed after a restart; the job stops at its budget; a final report puts the parts together. Waiting on use: a real multi-hour job to tune the plan and the per-part limits.
5.5 More channelsBuilt (2026-09-29): iMessage on the Mac (Messages' database read-only with Full Disk Access, answers through AppleScript; tested with a copy of the database's tables) and personal WhatsApp through a local WAHA bridge, off until chosen in Labs, with the ban warning, and never a way to approve (tested against a fake bridge). Waiting on the owner: a live test with a second Apple ID and with WAHA on a number that can be lost.
6.1 A login per personBuilt (2026-09-30): the first visit creates the administrator's account (name, then a passkey); devices belong to a person and act only for them; the administrator pairs a phone for someone; removing a person revokes their devices. In Portuguese the role is called administrador.
6.2 Privacy between peopleBuilt (2026-09-30): an access rule for every route (tested), everything personal scoped to its person with the owner seeing none of it, members answering their own approvals, others' events streamed as types only; a test calls every route across people.
6.3 Passkeys and sessionsBuilt (2026-09-30): passkeys per person in Account (go-webauthn), a sign-in screen, passkey sessions that expire after 30 unused days and devices after 180, a limit on wrong sign-ins (requests without a credential do not count); tested end to end with a software authenticator, including a forged signature and a removed person. Waiting on use: trying it with Touch ID, an iPhone and Windows Hello.
7.1 Widgets and snapshotsBuilt (2026-09-30): widget.show with seven kinds, snapshots and history, ready-made widgets, routine health widgets, private to each person and shared with the house on request (RFC 0003).
7.2 Dashboards in the appBuilt (2026-09-30): dashboards in tabs, a grid to drag and resize, stacking on narrow screens, live updates, out-of-date marks and refresh that asks before spending.
7.3 Routines as widgetsBuilt (2026-09-30): requests to see or track something end in a widget of the fitting kind (explorer and compiler rules), and Turn into a widget on a routine's page redoes it with a widget, approved as a new version.
7.4 Floating widgetsBuilt (2026-09-30): in the desktop app any widget floats in its own always-on-top window on every desktop, dragged and resized, its place and size kept across restarts, closed while the app is locked and back on unlock; only this computer's Pimpo, with a capability that allows only dragging. Waiting on use: trying it on Windows and Linux.
7.5 Widget feed and Android widgetsBuilt (2026-09-30): the phone's widget key (wk_, only the widgets pinned to that phone, dies with the device) and GET /api/widgets/feed; Android home-screen widgets placed from the app or chosen from the launcher, refreshed every 30 minutes and on open, drawn for every kind with small charts, in 10 languages. Waiting on use: trying it on an Android phone (this computer's emulator image is incomplete).iOS and macOS widgets wait on the Apple Developer account (decided: not for now).
9.2 Push triggersBuilt (2026-09-30): routines that watch Gmail or Slack can turn on Hear of it as it happens. Gmail uses users.watch to a Pub/Sub topic and a push subscription to /push/gmail, verified by Google's signed ID token (audience and service account), then history.list with the person's own token wakes only their routines; watches renew daily and polling (hourly as a safety net, normal when the watch lapses) stays. Slack channel messages and mentions arrive over Socket Mode as slack.messages. A per-routine GitHub webhook checks X-Hub-Signature-256 and handles each delivery once. Tested against fake Google, Gmail and GitHub. Waiting on the owner: the Google Cloud setup (Push triggers) and Slack's extra event subscriptions; Gmail push works for mailboxes signed in with Google (today the administrator's).
1.2 Setup without Claude CodeBuilt (2026-09-29): the welcome screen sets every job up from what the computer has or from one API key, testing the main model. Proof without Claude Code: DeepSeek V4 Pro through opencode, 5/5 first-attempt accepted and passing the holdout, $0.06. Waiting on people: five new users reaching a routine unaided; waiting on keys: proofs on two API providers and on a local model (Ollama has no model installed here, and the disk has 9 GB free).
M10 A company of agentsPlanned (2026-10-01): RFC 0004 and the M10 section of the roadmap.
10.1 Companies, departments, roles and membersBuilt (2026-10-01, Labs, off by default): internal/company keeps companies with departments, roles and members in a tree under the CEO seat, checked whole on every change; the API under /api/companies, private to the company's person and its partners by grant; company.yaml export and import. No screen yet (10.3).
10.2 Context and rules in layersBuilt (2026-10-01, Labs): contexts (Markdown, the last 10 texts kept) and rules for the company, a department, a role or a member; the most specific layer with a rule decides, and a rule that allows what a broader one forbids is saved only as an exception, with the rules it overrides; company rules never go past the house's (the stricter verdict wins); a member's preview shows its brief and the verdict on each capability with the rule that gives it.
10.3 Companies in the appBuilt (2026-10-01, Labs): More › Companies when the lab is on: creating, importing and exporting a company; roles, departments and members; the org chart drawn by the app with no new library (drag a card onto another to change its boss; a list on the phone); in 10 languages, WCAG AA in both themes. Context and rules per layer on screen, with rules that go against a broader one saved only as marked exceptions, and What this agent receives showing a member's brief and the verdict on each of its tools.
10.4 Members' routines and agent tasksBuilt (2026-10-01, Labs): a member's work runs live (changes are made, through the house's and the company's rules, inside its role's tools and a cost cap of up to $5), one piece at a time per member and three per company, inside working hours, from a queue that survives restarts; agent routines on a schedule (every 15 minutes at most); compiled routines given to a member run as that member and wake its agent with company.wake, handing new items as data; pausing a member, a department or the company stops what it is doing and holds its routines. On screen: live state on the org chart, the Work tab with stop, giving work and agent routines in a member's window, giving it your compiled routines, working hours and pausing. Waiting on use: a real company working for weeks to tune the limits.
10.5 Working togetherBuilt (2026-10-01, Labs): tasks handed down the tree (or across a department when allowed) with a fixed handoff (objective and acceptance required) and a dossier of where they came from kept by Pimpo; reports back up to whoever gave them; questions that stop a piece of work until the boss (an agent, or the CEO on their channels and in Needs you) answers, the work then going on with what it did before and the answer, while the member takes other work meanwhile; a judge checks each handed-down task against its root and asks the boss before a stray one starts; refused: depth past 4, 10 open tasks per member, the same task twice, work handed back up. On screen: the Tasks tab with the board by state, handing a task, its dossier, and questions to answer in place; company questions in Needs you.
10.6 Meetings, reports and the company's memoryBuilt (2026-10-01, Labs): the company's memory (facts, decisions, lessons and minutes; a member's notes marked as its words, never rules) given to every member with its brief and searched with company.recall; meetings of 2 to 8 agents, 1 to 4 rounds, talk only, with a cost cap of up to $2 and minutes and decisions kept in the memory, called from the screen or by a member with company.meet; a summary of the week (work done and failed by member, tasks closed, questions waiting, cost) sent to the CEO on Mondays, without a model. On screen: the Memory tab with notes and meetings (transcript, minutes and decisions), and This week on the Work tab.
10.7 Deciders, autonomy and invariantsBuilt (2026-10-01, Labs): when a member's action would ask first, its autonomy matrix (the member's lines, then its role's, then the company's default, else a person) names who decides: the member itself, Jev with a threshold (sure yes goes, sure no is refused, unsure goes on), a model, its boss, a committee voting (majority or unanimous) or a cascade; every answer is kept with who gave it and what it cost. Only what the company's rules or the house's starting presets ask can be delegated; the administrator's own rules, the protection list and the capabilities that always ask still go to a person, and rehearsals are never decided. No capability a member can call changes its company. On screen: autonomy lines in a member's and a role's window and the company's default decider (on Decision levels).
10.8 Decision levelsBuilt (2026-10-01, Labs): levels per company (the suggested four: operational, tactical, managerial, strategic), each with who decides (the member, its boss, the head of its department or the CEO) and triggers (an amount over a limit, a risk, a kind such as price or contract, being public, words); a decision is at the highest level whose triggers fire. Questions the triggers leave below the top go to a classifier, and an unsure one goes to the CEO; strategic questions reach the CEO with the opinions of the bosses on the way. An action's level can only make its decider more careful, and an action the rules allow still goes to whoever its level names. A labeled bank of decisions checks that none of the CEO's is missed. On screen: the Decision levels tab with the suggested levels, each level's decider, route and triggers, the simulator and the log of decisions.
10.9 Costs in layersBuilt (2026-10-01, Labs): every cost of a company is booked for one of its members (work, judgments, decisions, meetings); limits for the company (day and month), departments (month) and each member's monthly salary, inside the person's and the house's limits (a company is never given more than its person's daily limit); a warning near 80% and, at a limit, work held or only a warning; each piece of work capped at what is left; a monthly forecast from agent routines and recent pace; cost per piece of work and per task done; work paid by a subscription kept apart at its API-price equivalent, counted in the limits only when the company says so, and waiting for the subscription's window instead of failing when it runs out of turns. On screen: the Costs tab and the estimate when hiring.
10.10 Members' own accountsBuilt (2026-10-01, Labs): a member's settings and secrets live under its own names, so every connector (mail and the catalog) reaches only that member's accounts; the company's shared accounts reach the members granted to read or act; kinds of account (service, machine, brand, a real person's) with a warning when a service's terms may not allow one; roles list the accounts they need, and their members wait for them; members never reach the person's accounts, phone, Mac apps, house, Google, music, notes or memory, and browse with a profile of their own. On screen: Own accounts in a member's window, the company's accounts on Costs, a key on the org chart when one is missing. One account per service per member for now.
10.11 GitHub and coding in a worktreeBuilt (2026-10-01, Labs): GitHub capabilities for everyone, routines and company members alike: github.repo, github.issues, github.issue, github.pulls, github.pr and github.checks read; github.issue_create, github.issue_edit, github.pr_create and github.pr_review are reversible; github.comment, github.merge and github.release are irreversible; each member uses its own token or a company account it was granted. code.workspace runs a member's coding CLI (Claude Code, Codex or opencode, chosen per member, with a model) in a git worktree and branch of its own per task under the company's folder, with that CLI's sandbox as an option (none for opencode), its own file and command tools, no Pimpo tools or web, an environment without the vault or the person's git config, the company's coding variables and a cost cap; Pimpo commits as the member and pushes with its token, and worktrees of finished tasks go away. On screen: Coding in a member's window and Variables for coding in the company's settings. Checked live on 2026-10-01 with Claude Code (sandbox on) and opencode, each writing a file in its folder; Codex was not installed here and is not checked live yet.
10.12 The pilotWaiting on the owner: a project manager and two developers on Pimpo's own repository for two weeks, from the software company template, with their own GitHub tokens and coding CLIs, measuring the share of pull requests accepted without rewriting (60% or more), the cost per accepted pull request against its cap ($5 by default) and that no action left the matrix. Everything it needs is built.
10.13 Product owner and project managerBuilt (2026-10-01, Labs): signals kept with company.signal, the same page or nearly the same title counted on the first with every place it was heard, and read most-heard first with company.signals; briefs with company.brief: problem, proposal, claims that each cite a source and quote it, scores from 1 to 5 and the roadmap's formula, predictions; Jev flags claims whose quote does not support them and those that quote nothing; a person accepts, rejects or marks them shipped, and the author is asked on days 30 and 90 to check each prediction with company.brief_review, its accuracy shown; company.standup gives a project manager its team's last day, kept as a standup note; github.issue_create turns acceptance criteria into a checklist. On screen: the Product tab and briefs in Needs. The weekly radar that earns proposing is part of the templates (10.17) and earned autonomy (10.16).
10.14 FinanceBuilt (2026-10-01, Labs): costs.read gives a month of the company's spending with Pimpo by member and department, against its budget and the month before, the subscription equivalent and anomalies (a day over twice the median of the two weeks before it, a member on pace for 1.5× last month); a read-only Stripe connector (stripe.balance, stripe.charges) and github.sponsors for what comes in; on the first of each month each member with costs.read is asked once for last month's report, kept as a report note; company.budget_propose proposes a monthly budget for the company, a department or a member, which a person applies or keeps as is, within their own limit. On screen: anomalies and proposals on Costs, proposals in Needs. No money moves.
10.15 Media and publishingBuilt (2026-10-01, Labs): media on this computer: media.voice (the routines' voice), media.capture (a screenshot in the member's own browser, for allowed hosts), media.render (scenes of an image, a voice and a caption in ffmpeg as a tutorial 16:9 up to 20 minutes or a short 9:16 up to 60 s, at −14 LUFS with captions as a subtitle track) and media.check (length, aspect, loudness and captions, run on every video before anyone is asked), with the Media tab; publishing: youtube.upload (only a company video that passes its checks, always private, marked as synthetic media), youtube.publish (irreversible), youtube.stats, linkedin.post on the company page, and publish.assisted for networks Pimpo does not post to; everything a member publishes ends with the company's AI disclosure. Rendering is tested for real on Linux in CI and was run on the maintainer's Mac too. YouTube and LinkedIn are tested against fake servers, not live accounts.
10.16 Earned autonomyBuilt (2026-10-01, Labs): each person's answer to a company member's action is counted per member and kind of delivery (the capability); after the company's run of approvals in a row (10 by default, 1 to 100, or off) with no no in between, Pimpo suggests in Needs letting the member do it alone; accepting adds an autonomy line marked as earned, and a later no takes it back. The decision levels and what always asks stay above it. On screen: the suggestion in Needs, the setting on Decision levels and the earned mark on autonomy lines. Corrections a person makes outside Pimpo, after the fact, are not seen; taking a line away by hand returns that kind to approval.
10.17 Templates and the showcaseBuilt (2026-10-01, Labs): six templates built into Pimpo (software company with product owner, project manager, two full-stack developers, CTO, marketing and finance; marketing agency; online shop; content channel; consultancy; blank), each a company file with roles, capabilities, context, rules, levels and routines; creating a company by describing it: a model proposes it as a company file, checked whole, with capabilities Pimpo lacks left out, shown for review and created only when the person says so. Each member's performance on Work (work done and failed, minutes and cost each, tasks closed and stuck, questions, kinds earned, brief accuracy, videos passing), and two company widgets for dashboards (a summary and the month's spending by day), drawn only for people who may view the company. And an optional public showcase at /showcase/<address>, off until the company's creator turns it on and changed only by them, with only the shipped briefs, uploaded videos and https links they put on it, naming no one. The templates ship inside Pimpo; a gallery of templates signed like routines is not built.
10.18 Talking with members, and meetings with the CEOBuilt (2026-10-01, Labs): meetings the CEO takes part in, live: the agents spoken to (everyone, the chosen ones or those named with @) answer in turn, each hearing the others and knowing its recent work and the company's memory; a conversation with one agent from its window; talking over a question an agent asked before answering it; any answer turned into a task with the conversation as its context; ended with minutes and decisions kept in the memory; talk only, with a cost cap. On screen: the Meetings tab and its room.
10.19 Memory per task, per agent and per companyBuilt (2026-10-01, Labs): three memories, the company's, each agent's own and each task's; a member keeps a note in any of them with company.remember and reads the company's, its own and those of its task and the tasks above it; each company says per memory whether members write freely, after a decider (any of the company's: a person, the boss, Jev, a model, a committee, a cascade) or not at all, by default freely to their own and their tasks' and after a person for the company's; notes waiting for approval reach no one and show in Needs; with automatic notes on, Pimpo keeps what each finished piece of work did in its member's and its task's memory. On screen: the Memory tab with the three memories, the notes to approve and the rules of each.
Laya as judge and deciderBuilt (2026-10-01): Laya, Jev's open decision model, speaks Jev's API (/v1/systemone), so Pimpo's Jev client asks it too, with the model laya, a key only when its server has one, and its health probe. It is a judge backend of its own (laya), the first of the local chain when its address is set, and a company decider with a minimum certainty; Settings › Models tests the connection. Tested against a stand-in server speaking its API; not yet run against a real laya-serve, which needs Python and the model's weights here.

Pending decisions for the owner#

This page is built from the repository's documentation. Improve it on GitHub.