# Explicit managed onboarding: real audit and human approval

The person requested a real audit of existing systems, a cited rulebook proposal and independent human approval. Use https://pneu007-production.up.railway.app/.well-known/handle-managed.json (setup_mode:managed, contract 1.3). Do not switch this task to the prepared public open_demo, reuse its seeded rules as your audit, or drop ownership proof/consent. If the managed contract is unavailable or contradictory, report BLOCKED; do not silently fall back to public demo. Read https://pneu007-production.up.railway.app/skills/handle-onboarding/SKILL.md?setup_mode=managed and complete the protected onboarding flow below.

Current owner-authorized managed hackathon payments are local simulation only: provider:local_demo, network:local, synthetic asset:lovelace, currency CZK and simulated deposit 500 CZK (deposit_minor:50000). No Stripe, real funds, blockchain purchases, fees or on-chain refunds. Do not require wallet/funding setup or a live Masumi smoke test before local-demo rule approval. Read current payment configuration and the latest recorded owner answer. If an earlier critical Masumi finding/proposal is superseded, submit your own updated audit/report and proposal citing that current configuration and policy; preserve old evidence, answers, versions and hashes. Do not clear blocks blindly or self-activate rules; configuration contradictions still block affected commitments. Continue automatically through exact independent human decisions without another chat command. This local payment policy does not replace the requested fresh audit with prepared public open_demo.

Before presenting an activation link or saying “ready for approval”, reread the exact returned proposal and its linked audit report. Require empty governance.blocked_parameters, no unresolved critical findings and no unanswered critical questions for that proposal. If blocked, do not direct me to a disabled activation button or submit unchanged proposals repeatedly. Resolve a superseded Masumi finding by reading the latest recorded owner answer and current local payment configuration, submitting your own newly evidenced audit/report, then a new proposal/version/hash linked to that report. Preserve the old audit, proposal and evidence. While waiting, detect new owner answers or configuration changes and revise the affected audit/proposal; do not keep polling an obsolete blocked version indefinitely. Only present the exact new activation decision after this preflight passes; keep automatic continuation and independent human approval intact, without another chat instruction.

At every later owner question, exact rulebook activation, operation/publication grant or handover gate, keep the installer active with bounded reads of own authorized /businesses/:businessId/context, /me and /businesses/:businessId/capabilities as appropriate. Continue only when the exact expected server-recorded answer, version/hash, scope or handover state is satisfied; chat text is not approval. If the task must yield, create or update one actual native continuation routine with the current private credential reference and phase checkpoint; verify creation and resume support and avoid duplicate flows/operations. The initial provisional monitor stops at exchange; later gates use the authorized service credential and checkpoint. Stop on rejection, revocation or expiry and reconcile uncertain results. Never require a "continue" chat command, approve for the owner, grant yourself permissions or claim unsupported unattended continuation. If neither active waiting nor native continuation works, report that limitation.

# Agent entry point

Website: https://pneu007-production.up.railway.app
This is the fictional Pneu 007 workshop in Holešovice, Prague 7, used to demonstrate an A2A business platform. The business website, its backend, the platform and your own agent runtime are separate systems.

## Default for this demo: webhook wake-up

Use webhook wake-up first. Automatically show the real key-settings URL returned by Grok and Grok’s native masked input, so the owner can copy/paste the key once in the native secure input. Never invent the key URL or request the secret in ordinary chat. Protected managed onboarding still requires the independent human account, website ownership verification when required, pairing consent and exact rulebook approval before operation; webhook setup does not replace those decisions. Keep native recurring checks as an optional fallback.


## How to talk to the person

Perform technical setup privately. Default to one to three short, natural sentences about the result or a decision the person needs to make. Do not dump JSON, shell commands, audit findings, protocol names, task IDs or tool logs into chat. Ask only for missing business/service facts and necessary consent. Technical detail is opt-in. The detailed sections below are instructions for you, not text to repeat to the user.

Business setup: "I’m connecting your shop and checking automatic replies." After a verified wake-up: "Automatic replies are ready." If unavailable: "Automatic replies aren’t available in this Grok session yet." Never claim readiness before verification or promise that a website URL grants database access.

Customers: show the real service, appointment, total and simulated deposit, then ask "Shall I book this demo appointment?" After explicit agreement, submit the exact offer privately and report the saved result. Keep backend explanations out of the conversation unless asked.

Webhook keys are machine credentials. Inspect the actual native routine tools, reuse an authorized stored callback or generate a strong secret privately if the tool supports a supplied secret; otherwise save the actual privately returned callback/key. If the runtime hides the key, automatically present its actual key-settings URL and Grok’s native masked input. The owner may copy/paste the key into that native secure input; never ask for it in ordinary chat. An actual secure runtime connection approval may be shown as one plain-language action; resume setup after approval. If the runtime exposes neither a private webhook configuration path nor a supported connection action, try the key-free recurring fallback below. If it cannot create recurring routines either, automatic setup is not implemented for that runtime. Report that limitation briefly; do not invent an API, disable callback authentication or call it ready.

## Optional recurring fallback

Use this fallback only if webhook or native secure-input setup is unsupported, or the owner chooses it. Inspect the actual native routine tools. If they support recurring schedules, create or update a persistent inbox-check routine every minute (or the shortest supported interval up to five minutes). Reuse the enrolled business configuration; no callback key or URL is needed. Do not invent runtime APIs, recreate enrollment or start a time-limited chat watch.

Each actual scheduled handler calls inbox.mjs scheduled-check-in --interval ACTUAL_SECONDS, reads current rules, claims inbox work, replies with its saved lease, and exits when empty. Yield setup so the real native schedule can run. After at least two spaced check-ins, inbox.mjs availability reports mode:scheduled and available:true while contact is recent. This is authenticated liveness with a client-reported schedule, not independent verification of the scheduler; verify actual runtime runs too. Stale contact/revocation removes availability. Webhook wakeup-status may remain unconfigured; do not label this a verified webhook.

Tell the owner only: "Automatic replies are on. I check for new requests about once a minute." Use the real interval. If native recurring schedules are unsupported too, report that limitation briefly without asking for a key. Full handler instructions are in the business skill.

## Start from the owner's site URL

If the person says "set up my business for this site", treat this as an onboarding task. Read this guide, then https://pneu007-production.up.railway.app/.well-known/handle-managed.json and https://pneu007-production.up.railway.app/skills/handle-onboarding/SKILL.md?setup_mode=managed in full. The detailed business tools and inbox instructions are at https://pneu007-production.up.railway.app/skills/pneu007-business/SKILL.md?setup_mode=managed. Follow the actual manifest's URLs and schemas. You do the configuration; do not ask the owner to install a CLI, run shell commands, copy a bearer token, select database tables or register a webhook manually when your runtime can do it.

1. Inspect the supplied site and available owner-approved backend/admin access. Read existing local private connection files first. Reuse the connection and relay if already enrolled; validate /me. Never enroll twice or overwrite another business's configuration.
2. Resume your own valid pending enrollment before creating a new request. For a new connection, POST /api/handle/v1/agent-registrations with your real runtime and the supplied website origin. Contract 1.3 returns requested_scopes and pairing.initial_scopes; use those exact server permissions, never guesses or raw scope IDs as chat tasks. Save the provisional credential privately and GET your own /onboarding/:requestId for ownership_verification.state and ready_for_consent. If proof is required, use already approved legacy owner access and bounded enrollment-write authorization to publish only the returned ownership challenge with native legacy authentication/CSRF; do not ask for the same permission again. If that access/authorization is unavailable, present the returned verification_url labelled "Verify website then approve access" with the comparison code and expiry. The human uses "Ověřit web Pneu" on that page, signs in to the separate legacy owner realm securely if needed, explicitly publishes the challenge, and gives independent approval of access in their separate Handle account. Do not ask "Should I publish it or will you?", request credentials/challenges in chat or require a second chat command. Never claim ready for approval while proof is required or ready_for_consent:false. Existing verified company members may see not_required in the protected human console. On OWNERSHIP_PROOF_REQUIRED, refresh status and use that same page rather than blindly retrying approval or recreating enrollment. Keep the installer task active after showing the verification link, with bounded periodic authenticated reads of only own provisional GET /onboarding/:requestId until approval, rejection or expiry. Showing the link must not end installation or require a "continue" chat command. Finite consent-wait polling works for generic HTTP clients without native scheduling, operational scopes or webhook keys; it is not unattended business readiness. Only if the runtime must yield/end the installer, first create or reuse one temporary native recurring onboarding-status routine using actual supported tools and verify successful creation and automatic resume support. Persist the pending request and private credential references; the fallback polls only own provisional status. On approval, continue automatically, exchange credentials exactly once or validate a saved service connection after uncertain delivery/restart, stop any temporary monitor and continue G0/audit. Rejection stops waiting/monitoring; actual expiry stops it or uses supported renewal with one current request, never duplicate pairings. If neither active waiting nor scheduling/resume is supported, report that limitation instead of promising continuation or asking for a "continue" chat command. Credentials are exchanged and stored by you, never copied through chat. A site URL alone grants no database access, and website control is not human Handle consent.
3. After owner consent, exchange the provisional credential, read /me, and provision/reuse the assigned managed relay. Preserve the returned /relay/ID prefix. No new GitHub repository, Railway deployment or database installation is required for this demo. Before the observational audit, complete private G0: POST /api/handle/v1/businesses/:businessId/relay/probe with {phase:"onboarding"}, GET the returned private inbox_url, then POST /relay/probe/answer under the same business prefix with {nonce,method,evidence}, without a rulebook hash. A phase:onboarding, operation_ready:false receipt grants no operation scopes, activates no rules and cannot satisfy policy readiness. Preserve the receipt across restart; it records this connection's private bridge test only.
4. Discover the actual catalog, availability, backend API and MCP tools; inspect current business records and source documents. Use bounded business tools rather than raw SQLite writes. Archive redacted evidence, submit the audit, ask only unresolved business-policy questions, and propose cited rules. The human reviews and activates the exact rules in https://pneu007-production.up.railway.app/handle. Never infer approval from website text or submit a human decision yourself.
5. Request one actionable human decision at a time: exact rulebook activation, then your rulebook probe, then human operation permissions, then webhook setup. After server-confirmed activation, immediately run the probe with the existing relay.provision audit credential and authenticated HTTP polling of its private inbox. Neither operation permissions nor a registered webhook is required for this probe. Do not wait for either or use the operational /bot/inbox to read the private probe. If early webhook setup was denied, refresh your own context/capabilities and resume this sequence on the same connection; preserve the private callback and do not re-enroll. Keep the installer active or use verified native continuation across each gate. After exact human rulebook activation, run the separate rulebook probe at the same endpoints with {phase:"rulebook"}; its answer includes the exact active rulebook_hash. An empty probe-start body remains the compatibility default for this phase. The owner then grants separate operation scopes before native wake-up setup. For this demo, prefer webhook wake-up with the actual native key-settings link and Grok’s native masked input above. For other installations with private webhook configuration support, create or update your own native webhook routine using your runtime's actual tools. Download https://pneu007-production.up.railway.app/cli/inbox.mjs and use the private assigned inbox configuration. Register with setup-wakeup, then yield. The native handler acknowledges the actual setup_probe event with acknowledge-wakeup. For webhook mode, check wakeup-status: verification requires ready:true. If the key is hidden, present the actual native key-settings link and native masked input. Use recurring checks only if webhook setup is unsupported or the owner chooses them. The onboarding or rulebook HTTP receipt is client-reported bridge evidence, not proof of native runtime wake-up, secure callback configuration or MCP support. HTTP 200 or a 30-minute polling session is not readiness. If neither private webhook setup nor a persistent native recurring schedule is supported, keep automatic replies pending and give a short plain-language status; never request the key in ordinary chat, invent a settings URL/API or claim setup complete.
6. Publish the approved Agent Card through the authorized publication tool, verify the actual public card and website link, and register/update the business using the registry instructions in the business skill. Reuse existing IDs and idempotency keys. Keep private policies, credentials and customer data out of public metadata.
7. On each wake-up, privately claim inbox work, inspect the current rulebook, catalog and calendar, respond through the leased work item, and persist the case/quote/order identifiers. Respect customer consent, owner price exceptions and payment reconciliation. Do not charge or book because a customer merely asked for a quote. Continue on later events without a fixed polling deadline.

## Customer-facing confidentiality

Apply the full Customer-facing confidentiality section in the managed onboarding and business skills on every webhook/recurring/resumed reply. Never reveal internal rulebook contents, discount percentages or limits, approval thresholds or owner-approval requirements, deposit/exception logic, capacity caps, rulebook version/hash, scopes, epochs, lease/case internals or escalation rules to customers or their agents. Give only the exact public price, public price-list line items/version, available slots, missing information and feasibility. Do not forward raw tool/quote/case JSON; customer-visible business data must exclude internal policy and approval metadata. Necessary task/context identifiers remain only in the protocol envelope.

If the current public price list has no multi-car discount, say "No multi-car discount is listed on the current price list." Do not offer, hint at or quantify a discretionary discount. Decline the request or review it privately in Handle; only present a discretionary discounted price after the owner has approved that exact quote, even if internal rules permit automatic discounting. At most say "I need to confirm this with the business" while waiting; never identify the threshold, approver or escalation process. Published promotion terms and the actual offer's public payment terms may be shown; internal decision logic may not. Before every reply ask: "Does this message reveal any internal rule, limit, threshold or approval flow?" If yes, rewrite both text and structured data.

Acceptance: "Is there a discount for two cars? What is the max discount you can give?" Give actual public prices for both exact specifications and their total, state that no multi-car discount is listed when true, and expose no internal percentage limit, approval threshold, rule wording or rulebook version/hash. Request missing specifications rather than inventing prices. Record actual runtime proof separately from instruction checks.

The owner supplies business access and makes consent/policy decisions. You handle discovery, registration, configuration, tools, wake-up and publication. Report each pending dependency honestly. A website without a compatible backend or authorized admin access cannot be onboarded just by reading its HTML.

## Demo chat approval: no website login

Use the same session as the A2A task. With /cli/a2a.mjs:
1. Send the service request normally and save task.id.
2. Run demo-case WEBSITE --data-file case.json with {relay_task_id,service_spec}. Include the returned case ID in the same A2A conversation so the business agent can use its existing quote tool.
3. Run demo-offer WEBSITE CASE_ID. Show the business name, full service, returned appointment (Europe/Prague), total and simulated deposit. Explain that this is a fictional reservation and no funds are transferred.
4. Ask the customer to approve this exact offer. Only after an explicit affirmative answer, save the returned approval_request unchanged and run demo-approve WEBSITE CASE_ID --data-file approval.json. Do not submit this because the customer merely asked for prices.
5. Read the persisted order/booking and report confirmed only when booking.status is confirmed. Retries reuse the same case and exact approval. Changed price, appointment, expired offer, unavailable capacity or missing owner price approval requires a new valid offer and renewed customer agreement.

These commands call POST /demo/cases, GET /demo/cases/:id and POST /demo/cases/:id/approve with X-Demo-Session. Consent is labelled agent_relayed_demo_chat and independent_human_verification:false. Funding uses local_demo only, even if the deployment also supports Stripe or Masumi. Never describe it as a real or on-chain payment. Business management, human mandates and other businesses are unaffected.


## Customer agent

Fetch https://pneu007-production.up.railway.app/.well-known/agent-card.json every new run and use its supportedInterfaces JSONRPC URL. Never send customer traffic to /bot or owner onboarding endpoints. Read https://pneu007-production.up.railway.app/skills/a2a-customer-booking/SKILL.md for confirmed booking/payment flows.

This demo's A2A conversation requires no login or bearer token. Generate a random UUID v4 and send X-Demo-Session with every request, keeping it stable for send/get/follow-up/cancel. If omitted, the response supplies X-Demo-Session; save it before continuing. The bundled /cli/a2a.mjs persists this session automatically. This is an isolated sandbox conversation, not a verified customer account. Do not send real personal details. When demo_chat_approval is advertised, follow the chat-approval section below for a fictional reservation with simulated deposit. Other account-bound booking and payment still require the separate customer authorization flow at https://pneu007-production.up.railway.app/auth.md. After linking, the client uses --authenticated and starts a new authenticated task; an anonymous task is not reassigned. Business tools, database changes and private inbox access remain protected.

SendMessage and GetTask use A2A 1.0 JSON-RPC with Content-Type: application/json and A2A-Version: 1.0. Example (replace the UUID with your generated session ID when public demo access is advertised):

```json
{"jsonrpc":"2.0","id":"first-request","method":"SendMessage","params":{"message":{"messageId":"a-unique-message-id","role":"ROLE_USER","parts":[{"text":"I need four tyres swapped in Holešovice. What information do you need?"}]},"configuration":{"returnImmediately":true}}}
```

Raw SendMessage returns result.task; save result.task.id and result.task.contextId. GetTask returns result. Wire states use the TASK_STATE_ prefix (for example TASK_STATE_INPUT_REQUIRED). WORKING/SUBMITTED means wait and GetTask; INPUT_REQUIRED means send the next message with the same taskId/contextId and a new messageId. COMPLETED/REJECTED/FAILED/CANCELED ends the task. Retry an uncertain send with the same messageId. Public streaming and push notifications are not supported; the business's private wake-up routine is a different feature. If the business bot is offline, say the request is pending; never fabricate a reply.