Build Log — Week of 2026-05-18

Citro Comm
,
1

Build Log — Week of 2026-05-18

Week: Mon 2026-05-18 → Fri 2026-05-22
Releases: v0.0.21 → v2026.521.3 (7 releases)
Merged PRs: 11

What shipped

Issue pipeline graph view (#58) — v0.0.23

The biggest feature of the week. Bizbox now has a dedicated pipeline graph view for any issue. Hit the new Pipeline tab on an issue detail page and you get a full ancestor-scoped tree: issue nodes, agent participation cards, deliverable nodes, hierarchy edges, and blocker edges — all pan/zoom-able. The server-side GET /api/issues/:issueId/graph endpoint walks to the topmost ancestor and returns the whole tree in one shot, so the UI doesn’t have to stitch it together from multiple list calls. This makes multi-agent execution flows legible at a glance instead of requiring manual traversal through detail pages. Contributed by @DennisDenuto.

Inbox: nested issue references under expanded parent rows (#57) — v0.0.22

The inbox now shows References and Referenced by as second-level nested rows under expanded parent issues, alongside existing child issue rows. The server list endpoint gained an opt-in includeRelatedWork=true flag that batches related-work loading once per result set. Child issues are deduplicated so they don’t appear twice. Keyboard navigation was updated to use stable nested row keys. Contributed by @DennisDenuto.

Multi-entity mention tagging in the editor (#61) — v0.0.22

The shared markdown editor now supports prefix-switched @ tagging for agents, issues, deliverables, and projects. Repeated @ characters switch domains; five @ characters close the picker. Deliverable links render as first-class pills and route to the correct entity pages. Wired into issue detail, new issue, and new project flows. Contributed by @ralphbibera.

ClickUp human approval configuration (#65) — v2026.521.2

Two new environment variables let operators specify exactly which ClickUp channel receives approval notifications, with fallback to legacy defaults. The notification message itself was also improved: clearer instructions for human responders, a better CTA, and an always-present “Open in Bizbox” link. Contributed by @adPalafox.

Heartbeat recovery: smarter outcome classification (#66) — v2026.521.3

The heartbeat recovery loop now treats terminal “ok” payloads as authoritative successes even when the adapter returned a non-zero exit code, as long as there is concrete evidence of progress (hasConcreteActionEvidence). Gateway timeouts are reliably classified as timed_out failures rather than ambiguous errors. New utility functions — readHeartbeatResultStatus, isHeartbeatResultSuccessfulStatus, buildAuthoritativeSuccessResultJson — centralize status logic. This reduces false-positive recovery attempts and duplicate completion comments. Contributed by @adPalafox.

Heartbeat: awaiting-human message ID reconciliation (#68)

A follow-on to the heartbeat recovery work in #66. The approval reconciliation loop now correctly resolves the ClickUp message ID for awaiting_human transitions even when the activity log entry was written before the notification delivery completed. A new resolveAwaitingHumanMessageId function checks the handoff details first, then falls back to the outbox tracking table using a deduplication key. Both “sent” and “enqueued” delivery statuses are handled. A new test covers the fallback path. Contributed b@adPalafox @adPalafox.

Rebrand visible UI copy to Bizbox (#63) — v2026.521.1

Setup screens, access gates, account menu, breadcrumbs, feedback prompts, workspace copy, routines, invites, plugins, settings, browser/PWA title — all now say Bizbox instead of Paperclip. Package names, CLI commands, storage paths, and internal compatibility identifiers were intentionally left unchanged. Note: export footers and “See more” links that reference paperclip.ing had their display text updated to “Bizbox” but the domain itself remains paperclip.ing — this is the live public product domain, not an internal URL. The domain migration is tracked separately. First contribution fro@cerkiner @cerkiner.

Document filename generation improvements (#62, #64) — v0.0.24, v2026.521.0

Two back-to-back PRs tightened up how Bizbox names document deliverable files. PR #62 added buildDocumentDeliverableFilename to prefer a slugified title over a generic key like “document” or “deliverable”. PR #64 extended this further: when a document’s stored title is null, the system now infers it from the first Markdown H1 heading in the body, and uses that inferred title for storage, display, and filename generation. A new document-titles.ts module centralises the normalisation logic. Contribut@adPalafoxd by @adPalafox.

OpenClaw: persist pairing keys on agent updates (#59) — v0.0.21

The saved-agent PATCH route now runs ensureGatewayDeviceKey(...) for openclaw_gateway configs before token persistence, matching the behaviour of the create path. Without this fix, switching an existing agent into pairing mode through an update would re-trigger pairing on every run. Contribut@ralphbiberad by @ralphbibera.

Docs: periodic accuracy update (#60) — v0.0.22

README.md, ROADMAP.md, doc/PRODUCT.md, and doc/SPEC.md were updated to reflect shipped capabilities: deliverables/work products are no longer listed as roadmap-only (the Deliverables milestone in ROADMAP.md was promoted from :white_circle: to :white_check_mark: shipped), the Deliverables section covers both file artifacts and issue-linked documents, and the operator UI section mentions the issue pipeline view. Docs-only, no behaviour changes. Contribut@ralphbiberad by @ralphbibera.

Why it matters

This week’s work is about making Bizbox’s own execution model legible — to the people building on it and to the agents running inside it.

The pipeline graph view is the most visible example. Multi-agent workflows have always been the core Bizbox primitive, but until now the only way to understand what was happening across a tree of issues was to click through them one by one. The graph view collapses that into a single screen: you can see which agents touched which issues, where deliverables landed, and where blockers are sitting. That’s not just a UI convenience — it’s the foundation for the kind of transparent, build-in-public narrative that makes a developer community trust a platform.

The heartbeat recovery improvements matter for a different reason: reliability. False-positive recovery attempts were generating noise — duplicate completion comments, unnecessary re-runs — that eroded confidence in the system’s output. Requiring concrete evidence of progress before treating a run as succeeded is a small change with a large signal: the team is taking the correctness of the execution record seriously.

The Bizbox rebrand is the most visible external signal this week. Every screen that said “Paperclip” now says “Bizbox”. For anyone evaluating the platform, that consistency matters. The domain migration is tracked separately and will follow.

The ClickUp approval channel configuration and document filename improvements are quieter but meaningful: they reduce the friction in the human-in-the-loop handoff path, which is the part of the workflow that most directly affects how fast a team can move.

Decisions made

Versioning scheme change. Starting this week, releases moved from the v0.0.x semver sequence to a date-stamped scheme (v2026.521.x). The transition happened at v2026.521.0 (previously v0.0.24). This makes the release date immediately legible from the tag name and removes the pressure of maintaining a meaningful semver minor/patch distinction for a fast-moving internal platform.

Opt-in related-work enrichment on the issue list API. Rather than always loading related work for every issue list call, the team added an explicit includeRelatedWork=true flag. This keeps the default list path fast and avoids accidentally coupling downstream consumers to fields they didn’t ask for.

hasConcreteActionEvidence as the success gate for heartbeat recovery. The team chose to require positive evidence of real progress before treating a run as succeeded, rather than trusting the “ok” status string alone. This is a conservative default that avoids suppressing recovery for runs that reported success without actually doing anything.

Trade-offs

Graph endpoint aggregates multiple datasets in one response. The /api/issues/:issueId/graph endpoint loads descendants, blocker relationships, participating agents, and deliverables in bulk. This is fast for typical issue trees but may hit payload-size or performance limits on very large trees. The team flagged this as a medium risk to revisit once the feature is exercised on real-world data.

Inbox row model now mixes full Issue rows and reference-summary-derived nested rows. Future row-component changes need to account for the fact that nested reference rows don’t carry all the fields a full Issue row does. This is a known coupling risk documented in the PR.

UI test execution for the graph view was not fully confirmed (#58). An existing jsdom/ESM issue under Node 19 blocked full Vitest execution for the UI test file in the development environment. Backend and focused UI tests were added, but the full UI suite wasn’t run locally.

What’s next

  • Graph view stress testing. The pipeline graph endpoint aggregates data at query time. The next step is to run it against larger issue trees and establish whether pagination or lazy-loading is needed before the feature is broadly used.
  • Domain migration. The Bizbox rebrand is complete at the UI copy layer. The paperclip.ing domain migration — updating the product URL in export footers and external links — is the remaining piece and is tracked in the backlog.
  • Vitest/jsdom ESM fix. The Node 19 ESM issue that blocked full UI test execution for the graph view needs a root-cause fix so the full suite can run in CI without workarounds.
  • Dev.to comment reply path. The community-reply-execution workflow needs a supported API path for posting Dev.to comment replies so approved responses don’t require a manual step.
  • ClickUp adapter import resolution. The package-root resolution workarounds in PRs #57 and #58 should be addressed at the source before they accumulate further.

Open challenges

  • Large issue tree performance. The graph endpoint and inbox related-work enrichment both aggregate data at query time. Neither has been stress-tested against companies with hundreds of issues and deep parent/child trees. This is the most likely place to hit a wall as usage grows.
  • Dev.to comment reply automation. The community-reply-execution workflow still treats Dev.to comment posting as a manual step. There’s no documented supported comment-create API path yet, so approved replies require a human to post them.
  • ClickUp adapter import resolution. Two PRs this week (#57, #58) included local workarounds for ClickUp adapter import resolution in development. The underlying package-root resolution issue hasn’t been addressed at the source and may resurface.

Get involved

Bizbox is building in public. Every item in this log links to the real PR or release — go read the diffs, open an issue, or start a thread.

If something shipped this week affects how you’re using Bizbox, or if you hit one of the open challenges before we do, we want to hear about it.