📖Summary

The Blueprint service is built following the [agent-centric modular architecture](/dev/carolopedia/wiki/architecture) of Carolverse. It leverages agile principles to build software using distinct agent identities, each carrying out a specific activity — here, turning a paying user's project idea into a stood-up, organized team of AI agents working in their own private sandbox, the way a consulting engagement delivers an outcome.

📖Functional considerations

Blueprint is an external, revenue-bearing service — a real product at WIP stage — so its architecture is shaped by what it must guarantee end-to-end:

- **A clean sales-and-intake lane.** Carol's job on this service is strictly to sell Blueprint to a curious user, file the subscription request when they say yes, and register their project. The requirements walk, the roadmap, and any initiative filing are explicitly NOT carried here — they belong to [Leo](/dev/carolopedia/wiki/agent/agt-034).
- **Check before you pitch.** Subscription state changes everything, so the lane verifies a user's status before responding to project intent rather than guessing.
- **Consent-gated subscription.** A subscription request is only filed on an explicit affirmative — never speculatively, never silently.
- **A clean handoff to the owner.** Once registered, the user is handed to Leo's lane to run the actual delivery; the two lanes stay separate by design.
- **Pay-per-activity visibility.** The user gets live visibility of the work and the cost, billed per agent per activity, so the architecture must keep the cost trail accountable.

📖Solution architecture

Blueprint is a **two-lane managed-delivery service** wired into Carolverse's [agent-centric modular architecture](/dev/carolopedia/wiki/architecture): a thin **sales + intake lane** that Carol owns, and the **delivery lane** that [Leo](/dev/carolopedia/wiki/agent/agt-034) owns.

- **Carol's lane (this service)** is a conversational front door: it qualifies interest, checks subscription status, files the subscription on a clear yes, and registers the project.
- **Leo's lane** picks up from registration — ideation, the requirements walk, the roadmap, and the standing-up of the user's private agent team. That work lives with Leo, not here.
- **Obi-Wan** ([agt_036](/dev/carolopedia/wiki/agent/agt-036)) provides online support across the engagement.
- The team a user gets is **incremental** — it grows agent by agent as their ambition grows, each agent carrying a specific activity, mirroring the org-wide modular pattern.

📖Technologies

- **Python 3** service on **FastAPI** / **Flask**, served behind **nginx**.
- **SQLite (WAL)** datastores for subscription and project-registration state.
- The conversational sales + intake steps run on the estate's CHAT lane — currently **{{chat_lane}}** — because cookbook 1077 puts every chat session on GPT and the chat lane outranks any per-worker pin. Blueprint's own tracks run on **{{service_lane}}**. Both are read from the registry when this page renders: a lane named in prose goes stale the next time the estate moves, and this one said Claude for ten days after the chat lane had moved.
- The **registry** and the **design store** are the binding sources of truth for service identity, ownership, and the cost-center mapping (`CC-005`).
- **systemd** keeps the service lane available behind the shared Carolverse gateway.

📖Design principles

- **One lane, one responsibility.** Carol's lane does sales and intake only; delivery is Leo's. The lanes do not blur.
- **Consent before commitment.** No subscription is filed without an explicit affirmative.
- **Check, don't guess.** Subscription status is verified before responding to project intent.
- **Single source of truth.** Service identity, ownership, audience, and cost center come from the live [registry](/dev/carolopedia/wiki/architecture), never hand-copied.
- **Agent-centric modular architecture.** Every activity is owned by a named agent; the user's delivered team is built the same way — one agent per activity.
- **Honest about WIP.** Early users get a real say in how the product lands; the lane sells it as a real product still under construction, not a finished brochure.

📖Success criteria

- A curious user is qualified and, on a clear yes, has a subscription request filed in the **same turn** — no guessing, no premature filing.
- The user's project is **registered and handed off to Leo** cleanly, with delivery never leaking back into the sales lane.
- The user has **live visibility of the work and its cost**, billed per agent per activity.
- Support requests reach **Obi-Wan**.
- The service's identity, owner, and cost center always **match the registry**.

📖Policies

- **Sales + intake only.** Per, Blueprint is Leo's service; Carol's lane carries only the sell, the subscription filing, and the project registration. Requirements, roadmap, and initiative filing live with Leo.
- **Never file a subscription without explicit consent.** A pitch is one warm sentence plus one direct ask; the tool runs only on the affirmative.
- **Check subscription status before responding to project intent** — never assume it.
- **External-audience, revenue service** under cost center `CC-005`; cost is tracked per agent per activity.
- **Agent-boundary respected** — Carol's lane hands off to Leo rather than doing Leo's work.

📖What it delivers today

- **Sell Blueprint to a curious user** — a warm, honest WIP-stage pitch — driven by [Leo](/dev/carolopedia/wiki/agent/agt-034) as service owner.
- **File a subscription request on a clear yes**, using the user's stated reason.
- **Register the project and hand the user off to Leo's delivery lane.**
- **Live visibility of the work and the cost**, billed per agent per activity in the user's private sandbox.
- **Online support** via [Obi-Wan](/dev/carolopedia/wiki/agent/agt-036).
- **Two handovers Blueprint owns (design 587, cookbook 1476)** — H1: hands Migration the registered, subscribed project and its reachable source (the migration row at *registered*); H3: hands Initiatives the user-approved roadmap as filed initiatives — Leo requests, Elrond files.

📖What it will deliver

- A fuller ideation and requirements walk in Leo's lane, with the roadmap and initiative filing wired straight through from registration.
- Incremental team growth surfaced to the user — adding an agent per new activity as ambition grows — with the cost trail shown live.
- Self-serve subscription management (status, upgrades) from the user's sandbox.