Build Log — Week of 2026-06-28

#architecture #automation #buildinpublic #devjournal

Build Log — Week of 2026-06-28

Release: v2026.630.0 · published June 30, 2026

Repo: zesthq/bizbox · 1 release, 3 PRs merged (2 in window, 1 from prior week included in release)

Shipped this week

🔗 Routine → Workflow Invocation Contract

PR #120 · @adPalafox · merged June 30 · +1,576 / -74 (30 files)

The biggest architectural addition this cycle: a versioned, company-local contract that formalises how a routine in autonomous mode can hand work off to a workflow. Previously, the boundary between routines and workflows was implicit; now it's a first-class schema with durable audit records.

What's in the box:

Three selector modes — explicit workflow ID, workflow key, or capability. Routines can target workflows by what they can do, not just by identity.
workflow_invocations table — every routine→workflow handoff is persisted with selector, payload kind, and a link to the resulting workflow run. Full audit trail, safe to replay.
Payload kinds — markdown or JSON, matching the existing workflow run model so downstream consumers don't need a new code path.
Zod validators covering the full envelope, each selector variant, and the routine invocation request body.
Versioned contract constant (ROUTINE_WORKFLOW_INVOCATION_CONTRACT_V1) — the version travels with every handoff so future breaking changes can be detected in the audit log.

This closes the open question from the V1 spec about how autonomous routines compose with workflows.

🗓️ Workflow Schedules

PR #118 · @ralphbibera · merged June 25 (ships in v2026.630.0) · +1,372 / -4 (22 files)

Board operators can now define recurring workflows with cron semantics — separately from the routine scheduler. Key points:

New workflow_schedules schema + migration (0080_workflow_schedules.sql)
Server tick loop picks up due schedules and enqueues workflow runs automatically
Full board UI on the Workflow Detail page: create, edit, pause, archive, delete
UTC-only; skips missed fires by design (no catch-up on deployment restart)
Covered by focused tests: validators, routes, service scheduling logic, and UI wiring

Ops note: 0080_workflow_schedules.sql must be applied before the new routes and UI activate. Any active schedules created after migration will be auto-enqueued by the server tick loop — operators should confirm this is expected before creating active schedules in production.

📋 Q3 2026 Public Roadmap Update

PR #119 · @adPalafox · merged June 26 (ships in v2026.630.0) · 1 file

The public ROADMAP.md now carries a new ✅ AI Workflows milestone. The evidence table in the PR links six workflow-related merges from Q2 that collectively justify marking this milestone done. Community members watching the roadmap will see the milestone when they pull or browse on GitHub.

Decisions

Versioned invocation contract over ad-hoc parameters. The team chose to encode the contract version as a first-class constant (ROUTINE_WORKFLOW_INVOCATION_CONTRACT_V1) rather than relying on implicit compatibility. The version travels in the DB row and can be read from the audit log, making future migrations detectable without schema inspection.
Capability-based selector as first-class option. Rather than requiring callers to know a workflow's ID or key, routines can now target "the workflow that advertises this capability." This decouples routine authors from specific workflow identities and makes multi-workflow environments more composable.
Workflow schedules are UTC-only with no catch-up. Missed fires on deployment restart are silently skipped. The team explicitly chose predictability over at-least-once delivery for scheduled workflow runs.

Trade-offs

Versioned contract adds migration overhead. Every future breaking change to the routine→workflow protocol requires a new version constant, a DB column or separate table, and a compatibility shim for in-flight invocations. The upside (auditability, backward compatibility) is worth it at current scale, but the path from V1 to V2 needs planning before the invocation surface is widely used.
Skipping missed schedule fires simplifies ops but surprises automation authors. If a deployment takes down the server for 30 minutes, any schedules that would have fired during that window are dropped. This is documented in the PR risks but is not surfaced in the UI. Teams relying on strict at-least-once semantics will need to pair schedules with a monitoring webhook or an idempotent retry layer.
Three-selector model increases dispatch complexity. Capability-based resolution adds a runtime lookup step and raises the question of what happens when multiple workflows claim the same capability. The V1 spec documents the resolver precedence but the UI does not yet expose which workflow would actually receive an invocation for a given capability. Worth revisiting before this pattern is used heavily in production routines.

Open challenges

Capability namespace governance. Now that routines can target workflows by capability string, there is no validation preventing two workflows in the same company from declaring overlapping capabilities. The resolver picks the first match by some ordering, but that ordering is not yet user-visible or configurable. A light namespace convention or a UI warning before this scales would reduce foot-guns.
0080 migration rollout coordination. The workflow schedules migration is a prerequisite for the new UI. Teams running rolling deployments need a strategy for the window between when the migration is applied and when the new server version is live — the old server will ignore the new table, so there is no rollback concern, but operators should confirm the migration order in their deployment runbooks.
Invocation audit log surface. The workflow_invocations table exists and is populated, but there is no UI or API route yet to query it. The data is there for debugging and compliance, but tooling to surface it is an open task.

Up next: API and UI surface for the workflow_invocations audit log · Capability namespace tooling · Community-requested workflow template library.