Cedar — Rocoto app prototype
Start with the Cedar product architecture: business setup → conversations → orders → Delivery Notes → collection → invoicing and Money. It owns the domain map, shared identities, scenario consistency and connection boundaries. The operations hub contract owns the current navigation, setup and daily-work refinement. The live preparation handover records the current build, provider proofs, publication and continuation plan.
One possible direction for Rocoto: a configurable workspace for sales, products, customers and
administration. cedar identifies this candidate; its market, problem and design can evolve.
Revisions live in Git. Another possibility gets a sibling directory under src/prototypes/,
including when it explores the same users or problem. Product adoption is a separate decision.
The “kit app” is this prototype: app.html loads main.tsx.
Published builds expose /cedar/ on the development host. /app.html and / remain development
compatibility entries; source revisions stay in Git. The old kit-hosted entry transitions through
the separately guarded gallery release, after this named development artifact is verified.
app/README.md gives local preview, build and verification commands.
Earlier audits and release receipts refer to this source as app/src/app/ (or baseweb/src/app/
before the repository split); their recorded paths and revisions remain historical evidence.
| Part | Source |
|---|---|
| Candidate UI and behaviour | App.tsx, areas, shell, and the model modules in this directory |
| Candidate fixtures and browser state | config.ts, day.ts, sale.ts; imports the shared scenario cast |
| Prototype provider calls | runtime-client.ts and the separately configured mock-api; these exercise selected providers, not the proposed tenant backend |
| Yape/Plin collection | Cedar payment specification owns the order-to-payment-request and automatic reconciliation flow; the native collection service supplies its persistent development API |
| Money and seller setup | Money specification, money model, browser store, and Money workspace: Prometeo account data, direct Yape/Plin requests and NubeFact invoicing with scoped fixtures and native HTTP integration |
| Sequential onboarding | Onboarding contract, demo entrance, setup flow; business/channel/catalogue state reuses the workspace models |
| Connected channels | WhatsApp provider/session, Unipile email and document review with email inside Cedar, the hybrid connection, Twilio/Deepgram phone with phone inside Cedar, the hybrid connection, and call interactions; shared private access and explicit provider proof |
| Shared kit | components, theme, and gallery; the gallery's app-primitives pages demonstrate Cedar-owned components |
| Shared illustrations | public tiles and library maintenance; painting-map.ts is this candidate's resolver |
| Founder design input | Peter's original situations brief, 21 August 2026, followed by the recorded directives in FEED-IA |
| Design and proposed implementation | System, interaction, AI, implementation, adoption plan |
These design and wiring documents describe Cedar's proposal. A sibling keeps its own specification,
fixtures and runtime configuration, and can explicitly reuse useful parts. The existing
rocoto-app-* browser keys and rocoto-runtime-base override belong to this candidate; another
candidate uses its own namespace or isolated origin. A trial can use an account Peter explicitly
selects, including his own account. Company Operations records its actual owner, consuming service,
environment and permitted operations and external effects; credentials stay in the selected consumer's
private configuration. The workflow covers review and adoption.
The company roadmap connects current
commercial priorities to the work issue where a product capability is selected for adoption.
The current payment exploration belongs to Cedar. The preferred route lets buyers pay with Yape, Plin or an interoperable flow, with automatic reconciliation to the originating order or document and a fee-free preference. The payment spec distinguishes this intended Cedar flow from the current provider harness and records the wiring, provider access and commercial evidence still to establish.
The declared Money runtime selects the current development/demo API and UI entry. Shared fixture lifecycle owns reproducible seeded records; the data remains linked to Cedar’s existing customers and Delivery Notes. Money records the UI → API → persistent evidence → provider boundaries. Rocoto subscription billing remains separate.
The September workspace refinement records the category hierarchy, two-step setup, phone/chat interactions and durable WhatsApp intake.
The live preparation release records Prep, country controls and the simplified disconnected call entry.
Development build receipts
Build the publishable artifact after committing the reviewed source: npm run build:app-en
records the checkout's current commit in cedar/prototype.json. One command produces both
entries — /cedar/ in English and /cedar/es/ in Castellano, generated from this same source by
the snapshot transform (Spanish snapshot) — so the receipt carries
entrySha256 and spanishEntrySha256 together and a publication names what was served in each
language. Before packaging, compare that
receipt with git rev-parse HEAD and the requested development release commit. The entry hash
must also match the generated HTML. The product receiver
preserves immutable generations; a corrected publication receives a new committed source and
fresh build. After activation, verify the public receipt, served HTML and prototype API code
together. Cedar's native collection service keeps its own declared development artifact and
private state, under the same owned experience.