Repository navigation
fix(build): stop collapsing primitive provisioning status to a shared boolean (#1044) - #1048
Merged
Merged
Conversation
…lanned badge (#1044) The Business systems grid collapsed ZeroInvoice, ZeroCommerce and OpenCapStack onto a single shared boolean — "does this company have any ZeroDB project at all" (entry.zerodbProjectId) — so three different primitives rendered an identical Live/Planned badge no matter what had actually been provisioned. Confirmed live against production company "silo": GET /api/build/systems returned provisioned:true for ZeroPipeline, ZeroInvoice and ZeroCommerce alike. The per-primitive truth already existed and was already being fetched. The route called resolveApp(companyId), read only zerodbProjectId and pipelineProvisioned off the entry, and discarded the rest — even though setAppProvisioned writes zeroinvoiceProvisioned, commerceProvisioned, capstackProvisioned, serviceosProvisioned, livestreamingProvisioned and socialgraphProvisioned independently per primitive at provision time, each documented in the registry as its own real signal ("Absent/false = still simulated"). Changes: - business-systems.ts: replace the shared zdb/pipelineLive booleans with PROVISIONING_FLAG_BY_PRIMITIVE, mapping each system card to the registry field that is actually its provisioning truth. A primitive with no flag (Community, Context Graph, Search & Discovery, Content Workflow, Intent-Casting Marketplace, Browser Agent) stays honestly Planned instead of borrowing another primitive's state. Opts are now a named, documented SystemProvisioningFlags interface. - systems/route.ts: thread every per-primitive flag off the already-fetched registry entry, and surface them as a primitiveProvisioning block on the response so the real state is inspectable rather than inferred. Two collapse bugs beyond the three named in the issue are fixed by the same wiring: ZeroPipeline was ORed with the shared flag (a bare ZeroDB project made it Live without any pipeline), and ServiceOS / ZeroVoice / Live Streaming / Social Graph / ZeroDB were hardcoded to false despite having real flags. The shared `provisioned` response field keeps its existing meaning (the company has its own ZeroDB project) for Live.tsx's cloud-provisioning banner. Verified in a real browser against a local dev server: a company with only ZeroInvoice provisioned renders ZeroInvoice as "✓ LIVE" while ZeroCommerce, OpenCapStack and ZeroPipeline render "● PLANNED".
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Addresses the product owner's request tonight to surface real primitive-provisioning status in the UI. Investigation found the mechanism already mostly exists — the Live dashboard's Business Systems grid has a real Live/Planned badge, and the registry already stores genuine per-primitive provisioning flags written independently at provision time. The bug was that several primitives were never actually reading their own flag.
Beyond the 3 primitives #1044 named (ZeroInvoice/ZeroCommerce/OpenCapStack), found 2 more instances of the same bug class:
Fix
Scoped wiring only — no new backend work, no schema changes, no new registry fields. Every value was already stored and already fetched; this just threads it through correctly via a named, documented `PROVISIONING_FLAG_BY_PRIMITIVE` map.
Important — visible behavior change, by design
This will make some production badges flip from Live to Planned. Companies whose ZeroDB project exists but whose individual primitive flags were never written (likely common — those are typically only set when a signed-in founder was present at provision time) will now correctly show Planned where they previously, incorrectly, showed Live. This is the honest, correct outcome the product owner asked for, but it's a visible UI change worth being aware of rather than being surprised by.
Test plan
Closes #1044