Repository links may require access. Source inspection is separate from a clean public-package installation.
AN INTERACTIVE READING MAP
Get the shape of this guide.
Move through the ideas, inspect their relationships, or make a focused reading path. The complete guide stays below.
⌘↗
READING SEQUENCEUnderstand how the ideas connect
Choose a point to look closer ↓
01 / Guide section
Separate requirement, connection and binding
An application can describe the capability it needs without embedding a provider account in its contract. The integration model distinguishes a service definition, a tenant's configured connection and the application binding that selects a connection for a named slot.
Read the supporting context ＋
This separation makes configuration review possible: you can ask what the product needs, which connection supplies it and where that connection may be used.
Explore a section, then continue with the complete article below.
1 / 4
Separate requirement, connection and binding
An application can describe the capability it needs without embedding a provider account in its contract. The integration model distinguishes a service definition, a tenant's configured connection and the application binding that selects a connection for a named slot.
This separation makes configuration review possible: you can ask what the product needs, which connection supplies it and where that connection may be used.
Concept
Question it answers
Keep out of it
Integration definition
What capabilities does this provider integration expose?
Tenant credentials
Tenant connection
Which account and environment are configured?
Unbounded permission inferred from an account name
Application binding
Which slot uses which connection?
An assumption that every workflow may use it
Host implementation
How is the actual effect executed?
Secrets in browser-visible configuration
↳Keep purpose, account and use separate.Trace the mechanism · 3 ways to look closer＋
A workflow needs to prepare a customer reply. Explore the record that answers each connection question.
What are you choosing?
A CONCRETE SITUATION
Name a capability without embedding an account.
The product needs a provider operation that can retrieve the relevant customer context.
01 / Purpose
Name the workflow and the information it needs.
What changes
An integration definition makes supported capabilities inspectable.
What stays explicit
Tenant credentials do not belong in the portable application requirement.
FOLLOW THE CONSEQUENCE
Choose the smallest useful operation. A definition does not establish that a selected account is configured or reachable.
Choose how the host resolves credentials, checks the selected connection and supplies the provider client. Keep secrets behind references or server-side access paths. Derive tenant context from the trusted identity boundary rather than treating an incoming tenant identifier as authority.
A capability declaration does not establish that credentials are valid, quotas are configured or a remote service is reachable. Those checks belong to the selected implementation and environment.
Progress from fixture to provider
Start with a fixture port to test the product behavior without external effects. Then run a provider-specific qualification in an appropriate test environment, including the relevant error, retry and duplicate-request cases.
Record which calls used real provider behavior. A deterministic local example can demonstrate your composition while leaving live service semantics untested.
Review a provider change as a behavior change
When changing a provider, compare supported capabilities, result semantics, rate behavior, idempotency and operational evidence. An adapter that satisfies a TypeScript interface can still behave differently in ways users notice.
Keep the application contract stable where that is intentional, and make any changed behavior visible through versioning, tests and documentation. Portability is achieved through those explicit seams.
See it in an example.
Agents / Intermediate
Draft freely. Send with approval.
Control side effects
Follow one contract boundary through a workflow and an in-memory MCP transport.
01
Separate the two operations
02
Inspect the workflow
03
Inspect the MCP boundary
Source demonstratesThe source smoke fixture drives a real MCP server/client over linked in-memory transports.
Does not demonstrateDelivery of a Slack message, email, invitation, or other network request.
Inspect the walkthroughBehavior · proof and limits · source checks＋
Follow the source behavior
A reference agent drafts a message, waits for approval, and invokes sendMessage. The MCP smoke test uses a real MCP server and client over an in-memory transport. The actual handlers remain deterministic fixture logic.
Separate the two operations
The source defines draftAndSend.draftMessage and draftAndSend.sendMessage. Drafting is automation-safe; sending declares its approval requirement.
Inspect the workflow
The example connects draft, approval wait, send, and receipt stages through the WorkflowDevkit adapter. This is a composed reference flow, not an invitation feature in the minimal starter.
Inspect the MCP boundary
The smoke test registers the operation registry as MCP tools, then calls sendMessage with valid, absent, and tampered receipt evidence. It expects success only for the valid case.
Read what send actually does
The bound handler derives a message ID and returns status sent in memory. To send through a real provider, supply your own port and preserve the same execution boundary.
What this example establishes＋
Source demonstrates
The source smoke fixture drives a real MCP server/client over linked in-memory transports.
The fixture asserts APPROVAL_REQUIRED for missing and tampered receipts.
The same registry gate is used by the MCP adapter rather than a second hand-written approval path.
Does not demonstrate
Delivery of a Slack message, email, invitation, or other network request.
A fresh successful run or production human approval system.
That the minimal example includes MCP; this is a separate source package.
Look inside the guideOpening context · complete reading path＋
Treat a feature as a set of declared dependencies
A larger feature often combines operations, policy decisions, UI surfaces and external services. Feature Hubs provide a way to make those relationships inspectable rather than burying them in application startup code.
Look inside the guideOpening context · complete reading path＋
Separate the decisions
Authentication establishes who is calling. Policy decides whether that subject may perform a particular operation in context. Scoped approval supplies evidence that a specific request or class of effects has been reviewed. A ceremony requirement can require additional, fresh verification at execution time.
Look inside the guideOpening context · complete reading path＋
Give each test one question
An operation has several boundaries, and one green check cannot answer every question about them. Separate declaration validity, business behavior, adapter behavior and external consumption so failures tell you where to look.
