PayCargo · AI-Sandbox · Process

6.eSDK capability roadmap

The complete vibe-scripter-facing surface, designed up-front from engineering pattern recognition (per §21) rather than discovered piecemeal. Sixteen capability groups, sequenced across Phase A through Phase D. Each capability has a named API surface that survives consumer addition; consumers validate but rarely reshape.

Block: 6.e (Console doctrine extension) · Pins: §19 (two-tier), §21 (experience pre-shapes)

1. The 16 SDK capability groups

#	Capability	Vibe-scripter import	Phase
1	HTTP / Lambda shell	`import { route } from 'vibecode-sdk';`	A
2	Auth context	`ctx.user`, `ctx.groups`, `ctx.permissions`	A
3	State persistence	`ctx.store.{threads,documents,keyValue,auditTrail,transient}`	A threads; B rest
4	AI / Bedrock	`ctx.agent.{invokeAgent,invokeWithTools,summarize,classify,extract}`	A streaming; C tools
5	Audit / observability	`ctx.audit.{emit,span,error}`, `ctx.metric()`	A
6	Cost attribution	auto via `invokeAgent()`; manual `ctx.cost.track()`	A
7	SoR helpers (user-context)	`ctx.{salesforce,github,monday,gitbook}`	B
8	Async / queue / batch	`queue.{enqueue,worker}`, `scheduled()`, `workflow()`	B
9	Cross-app events	`events.{emit,subscribe}`	C
10	Email (SES-backed)	`ctx.email.send({ to, subject, template })`	B
11	File handling	`ctx.upload.{beginMultipart,complete}`, presigned URLs, CSV parsing	B
12	PII detection + lockbox	`audit.detectPII()`, `lockbox.{store,reveal}`	A detector; B lockbox
13	Time / IDs	`ctx.{uuid,now,timezone,formatDate,formatRelative,parseUserDate}`	A
14	Pagination	`pagination.cursor()`, consistent across all `store.*.list()`	A
15	Validation	`validate.shape(input, schema)` — lightweight JSON-shape	A
16	Cache	`ctx.cache.{get,set}` with TTL; read-through for SoR calls	B

Bonus capabilities (covered by their own Step doc but consumed via SDK):

Capability	Source	Phase
Charts (SVG, design tokens)	`vibecode/sdk/v1/charts/`	A
Diagrams (interactive)	`vibecode/sdk/v1/diagrams/` (promoted from diagram-process)	A
Streaming chat UX	`vibecode/sdk/v1/spa/streaming-message.js`	A
WebSockets	`vibecode/sdk/v1/spa/socket.js`, `vibecode/sdk/v1/lambda/socket.ts`	Step 6.b — built on demand
Multi-step agents / tool use	`ctx.agent.invokeWithTools()`	C

2. Phase A deliverables — what ships this week

Phase A's SDK foundation:

HTTP shell (route() + auth context + audit middleware)
State persistence (store.threads only for chatbot)
AI streaming (ctx.agent.invokeAgent())
Audit / cost / PII detector — all five contracts validated
Time / UUID / pagination / validation — small utilities
Streaming-message UX (browser side)
Design tokens + components.css + utilities.css + logo + AppLogo renderer
Charts + diagrams SDK packages (promoted from existing)
app-template Terraform module
App Registry DDB + substrate _platform Lambda

Phase A chatbot consumes everything above. Vibe app 2's first day of Phase B starts with Phase A's complete SDK already in production.

3. The vibe-scripter handler shape

Reference target — what a chatbot handler looks like at end of Phase A:

// cartridges/engineering/chatbot/handler.js
import { route, agent, store } from 'vibecode-sdk';

export default route({
  'GET /api/threads': async (req, ctx) =>
    await ctx.store.threads.list(ctx.user.id),

  'POST /api/threads': async (req, ctx) => {
    const threadId = ctx.uuid();
    return await ctx.store.threads.put(ctx.user.id, threadId, {
      title: 'New conversation', messages: [],
    });
  },

  'POST /api/threads/:id/messages': async (req, ctx) => {
    const { content } = req.body;
    const thread = await ctx.store.threads.get(ctx.user.id, req.params.id);
    thread.messages.push({ role: 'user', content });

    return ctx.stream(
      agent.invokeAgent({
        model: 'claude-haiku-4-5',
        messages: thread.messages,
        attribution: { app: 'chatbot', purpose: 'user_chat', threadId: req.params.id },
      }),
      async (fullResponse) => {
        thread.messages.push({ role: 'assistant', content: fullResponse });
        await ctx.store.threads.put(ctx.user.id, req.params.id, thread);
      },
    );
  },
});

~25 lines. No BedrockRuntimeClient, no DynamoDBDocumentClient, no aws-jwt-verify, no CognitoIdentityProviderClient. The SDK does it all.

4. SDK velocity curve (per §21)

The compounding-interest shape applied to platform development:

Phase	Vibe code per app	New SDK code per app	Cumulative SDK
A (chatbot)	~50 lines	~500 lines	~500
B (Sales reports)	~50 lines	~100 lines	~600
C (vibe app 3)	~50 lines	~30 lines	~630
D (apps 4-10)	~50 lines each	~10 lines each on average	~700

By Phase D, new vibe apps ship with virtually no engineering work because every common need has already been encountered by an earlier app and turned into SDK surface.

5. Doctrine

Step 6.e doctrine: "The SDK is the platform's compounding investment."

Every helper written for vibe app 1 removes friction from vibe app 2. Every helper added for vibe app 2 removes friction from vibe apps 3 through N. The platform's quality at year one reflects the engineering team's discipline at design time, and the SDK's velocity-per-app curve is asymptotic toward zero. Discipline today is leverage tomorrow.