[pratikbuilds]

Problem

Local startup can reject four tool packages whose source has moved without a version bump, while CI's PR-relative freshness check misses stale changes already on the base branch. The dev launcher also starts a manually registered sidecar-dev that lacks the allocation or probe identity required by the hub. Separately, readiness polling checks the account's personal workspace instead of the selected workspace and treats lookup failures as an unknown state.

Runtime changes

Let the hub provision sidecars

scripts/dev.ts starts the hub and retains database setup, frontend build watching, and dev-account seeding. The hub's existing configured provisioner owns sidecar creation and credentials.

The removed startup path derives a token from the session secret and writes only a sidecar row. The hub still validates the token hash, but also requires a valid allocation with a workflow anchor or an active workflow probe. A bare row is insufficient. Removing the launcher and its unused ensureSidecarIdentity helper avoids duplicating that lifecycle. Existing database rows and schemas are unchanged.

One development behavior changes: the removed standalone sidecar uses --watch; the existing process provisioner does not. Hub and frontend watching remain. Sidecars follow allocation/probe lifecycle, not one process per message. Authentication and provisioner implementations are unchanged.

Repair provider setup and selected-workspace readiness

Provider seeding supplies the API origin for every seeded provider and repairs an existing provider only when its origin is missing. It preserves configured origins and also performs this check when a credential already exists.

GET /api/onboarding/provisioning-status requires tenantId, validates it, and verifies the caller's active membership before reading that workspace's provisioning status. The home page and new-workbench picker pass the selected tenant. Readiness failures return a visible error with a reference ID instead of being treated as preparation; the home page supports retry.

Align tool versions and CI validation

The package versions and assistant pins advance together:

Package	Previous	Current
catalog-tools	0.0.4	0.0.5
access-tools	0.0.1	0.0.2
interaction-tools	0.0.7	0.0.8
workflow-authoring-tools	0.0.4	0.0.5

The structural freshness command retains its PR-base comparison and calls the publisher's existing historical checker for all registered tool packages. The historical check compares source against the commit introducing the current version, including uncommitted and untracked source. It runs even without a PR base or origin/main. This uses Git history, not a live registry query.

Tests and review map

• scripts/checks/test/tool-package-freshness.test.ts creates a disposable Git repository with stale source already at origin/main. The command must fail with an empty PR diff, still fail without origin/main, and pass after a version bump.
• scripts/e2e/chat.test.ts enables the three existing mention/invite/direct-chat scenarios. They assert recipient run progress after posting, not generated reply text. The reuse scenario establishes its own chat and also runs independently.
• Onboarding tests cover selected-workspace access, visible readiness errors and retry, provider-origin preservation/repair, and repeated credential setup without duplicate resources.
• The workflow projection test spies on one database function and restores it after each test, preserving other database exports for later tests. Its valid fixture passes the real projection schema.
• Database bootstrap tests retain migration and reset coverage; the test for the deleted legacy identity helper is removed. Database creation, teardown, and migration replay have a 30-second test deadline so a five-second runner timeout cannot interrupt a full replay and leave the next test reading a partial ledger.

Suggested reading order: scripts/dev.ts and scripts/db-setup.ts; provider seeding and onboarding routes; frontend readiness handling; the freshness command and its Git fixture; chat and projection tests. README and AGENTS describe the resulting startup and validation behavior.

Validation

• The exact E2E unit-suite command passes locally: 25 tests, without a command-line timeout override.

• WORKBENCH_CHECK_CONCURRENCY=2 bun run check passes: typechecking, lint, workspace tests, and structural checks. Database-backed tests use the local test database, and hub data lives in a disposable directory outside the checkout. Lint reports 10 existing warnings and no errors.

• WORKBENCH_CHECK_CONCURRENCY=2 bun run build passes.

• Chat E2E: all 10 tests pass. The final self-contained reuse scenario also passes alone with --test-name-pattern 'kind filter'.

• The final chat test edit passes focused Prettier and ESLint checks; the branch passes git diff --check.

Live browser checks on the combined local implementation returned the requested reply before and after a hub restart. The recorded agent turns completed in 6.1 and 7.3 seconds. These are smoke checks, not a latency guarantee or proof that every historical delay is resolved.