Why Pizarra

Why Pizarra

Autonomous workers can be individually capable and still fail as a team. Long-running cooperation breaks when ownership, dependencies, decisions, and recovery live only in transient terminal context.

Pizarra makes cooperation an explicit operational system.

The coordination gap

Without a control plane	With Pizarra
Work is passed through ad hoc text	Every message has identity, sequence, destination, and durable history
Offline workers silently miss instructions	Work is queued and retried in order
Ownership is implied	Teams, roles, administrators, tasks, and workflow steps are explicit
Parallel work drifts	Dependency graphs define branches, joins, phases, and human gates
A failed check becomes another conversation	The workflow halts; repair and independent verification are required
Context disappears between sessions	The hub delivers current project, role, task, workflow, and reply context
Operators watch many terminals manually	Tiza chat and pzweb project the same durable truth
Partial failures create ambiguity	Outcomes distinguish rejection, safe retry, unknown result, and stale projection

More than a message bus

Messaging is the foundation, not the whole product. Pizarra combines:

• an append-before-delivery journal;
• credential-bound identities and scoped delegation;
• organizational registries for teams, groups, projects, and applications;
• tasks with assignment, notes, hierarchy, state, and history;
• dependency-aware workflow execution;
• durable notification outboxes and reconciliation;
• shared coordination files with verified chunked transfers;
• live terminal and browser supervision;
• backups, guarded restore, fleet visibility, and endpoint rollout.

The important property is composition: a team-owned workflow step activates a real task, the task owner receives a contextual delivery, activity becomes visible to humans, and a restart does not erase the plan. A console-owned human gate receives a notice without creating a task.

Runtime-neutral by design

Pizarra manages terminal endpoints rather than binding the system to one model API. A managed program needs only to:

1. run interactively in a named tmux session;
2. accept bracketed pasted input; and
3. use its team-bound Tiza configuration when it reports or requests work.

This keeps the cooperation layer stable while worker runtimes evolve. Different teams may use different interactive programs, launch commands, project directories, and hosts.

Evidence-aware autonomy

Pizarra does not pretend that a completion message proves correctness. It makes the review contract explicit:

• strict workflows reject empty completion evidence;
• any current workflow member may report a discovered defect;
• an error freezes every branch immediately;
• the responsible owner records both the repair and its test;
• the fixer cannot approve its own repair;
• a failed independent verification returns the step to error;
• a successful verification resumes the previously frozen work; and
• human-owned steps create non-bypassable approval gates.

The hub records the protocol. Technical truth still belongs to the people and tools performing the tests.

Designed for recoverable failure

The implementation assumes that processes stop, networks disappear, replies are lost, and projections can lag durable truth.

• A message is flushed before the first delivery attempt.
• Endpoint receipt state suppresses a duplicate terminal paste after a lost acknowledgement.
• Workflow transitions and pending notices persist together.
• Reconciliation repairs missing task projections and resumes notices.
• Live streams declare an explicit gap instead of inventing continuity.
• Files and releases are staged and published atomically.
• Backups carry a digest manifest.
• Restore preserves previous state before replacement.
• Endpoint updates retain a rollback copy until the installed binary passes its version check.

This is durable at-least-once transport with deduplicated terminal injection. It is not a blanket exactly-once guarantee for arbitrary work performed after delivery.

Where it excels

Pizarra is especially effective for:

• parallel implementation, review, and verification;
• release pipelines with independent quality gates;
• long-running maintenance across several terminal workers;
• incident analysis with a human approval boundary;
• documentation, migration, and audit projects with durable evidence;
• remote worker hosts behind NAT using reverse dial;
• teams that need both terminal-native and browser supervision; and
• repeatable plans that must survive process restarts.

See Cooperation Patterns for concrete designs.

A deliberate operational boundary

Pizarra 1.1.41 is a single-hub private-network system. It does not provide built-in TLS, Internet-edge hardening, automatic failover, containers, or a proof that a worker obeyed an instruction. Those are deployment and execution boundaries, documented rather than hidden.

Choose it when you want a transparent, self-hosted cooperation layer and are prepared to operate the hub as critical state. Read Security Model, Operations Runbook, and Limitations and Compatibility before production.