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.
• 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.

• Python 3 service on FastAPI / Flask, served behind nginx.
• SQLite (WAL) datastores for subscription and project-registration state.
• Claude (Sonnet/Opus) drives the conversational sales + intake steps.
• 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.

Blueprint is a two-lane managed-delivery service wired into Carolverse's agent-centric modular architecture: a thin sales + intake lane that Carol owns, and the delivery lane that Leo 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) 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.

• 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, 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.

• 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.

• Sales + intake only. Per CAROL-INI-727, 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.

Current

• Sell Blueprint to a curious user — a warm, honest WIP-stage pitch — driven by Leo 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.

Future (on demand)

• 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.

Agent-facing tools (Carol's sales + intake lane)

• get_my_subscription_status — check whether the user is already subscribed to Blueprint; call this BEFORE responding to any project intent, since the answer changes the reply.
• request_blueprint_subscription — file the user's subscription request once they give a clear affirmative; pass their one-line reason.
• relay_to_leo — hand the registered user off to Leo for the requirements walk, roadmap, and delivery, which do not live in this lane.

The flow

1. User shows project intent → call get_my_subscription_status.
2. Not subscribed → one warm sentence pitch + one direct ask; wait for a yes.
3. Clear yes → call request_blueprint_subscription on the same turn.
4. Registered → relay_to_leo to start delivery.

Where the rest lives

• Ideation, requirements, roadmap, and initiative filing are Leo's lane at /dev/leo-chat/ — not this service.
• Support requests route to Obi-Wan.