pomerado 0.1.2 → 0.2.0

package/README.md

@@ -4,7 +4,7 @@
 <p align="center">Describe what you want to do on a website. Pomerado builds an integration your agent can use.</p>
 
 <p align="center">
-  <a href="LICENSE"><img src="https://img.shields.io/badge/license-AGPL--3.0--only-blue?style=for-the-badge" alt="License AGPL-3.0-only"></a>
+  <a href="LICENSE"><img src="https://img.shields.io/badge/license-MIT-blue?style=for-the-badge" alt="License MIT"></a>
   <img src="https://img.shields.io/badge/node-24.21%2B%20%3C25-339933?style=for-the-badge&amp;logo=nodedotjs&amp;logoColor=white" alt="Node 24.21 or later in Node 24">
   <img src="https://img.shields.io/badge/pnpm-10.34.5-F69220?style=for-the-badge&amp;logo=pnpm&amp;logoColor=white" alt="pnpm 10.34.5">
 </p>
@@ -103,13 +103,13 @@ integrations/example_reader/
 ├── pomerado.json        Entrypoint and input/output schemas
 ├── deployment.json      Tool name, description, URL, intent and authority
 ├── mcp.mjs              Fixed launcher for the shared Pomerado runtime
-├── codex-mcp.toml       Local Codex server configuration
+├── mcp.json             Standard MCP server entry, with no key
 └── README.md            Commands and usage for this integration
 ```
 
-1. Open the generated `README.md` and `codex-mcp.toml`.
-2. Copy the generated MCP section into `~/.codex/config.toml`. It already contains your local Node, launcher and runtime paths.
-3. Make sure Codex can forward `OPENAI_API_KEY`. Generated integrations still use Guardian.
+1. Open the generated `README.md`. It lists the add command for each major MCP client, with your local Node, launcher and runtime paths filled in.
+2. Add the server to your client, or copy the entry in `mcp.json` into a client that reads an `mcpServers` file.
+3. Make sure the server gets `OPENAI_API_KEY` from its environment. Generated integrations still use Guardian.
 4. Reload the MCP configuration in your client and ask it to use the integration.
 
 > Use example_reader to read the page heading.
@@ -168,7 +168,7 @@ This repository owns the shared minter, Guardian, operation runtime and live aut
 | `typescript/src/execution/`    | Local workspaces, child processes and native Playwright adapter  |
 | `typescript/src/standalone/`   | Local library, terminal and MCP composition                      |
 | `typescript/src/mcp/schema.ts` | Pure schema adapter shared with the production MCP               |
-| `typescript/authoring/`        | Shared prompts and examples for local and hosted minting      |
+| `typescript/authoring/`        | Shared prompts and examples, with sections a host can replace    |
 
 <details>
 <summary>Runtime boundaries and browser compatibility</summary>
@@ -186,7 +186,7 @@ Here `kernel` is a compatibility object forwarding calls to native Playwright ov
 
 This public repository is the sole source for the shared core, portable tests, authoring assets and local MCP adapters. Cloud calls the installed library directly. Its hosted MCP frontend stays in the private repository with accounts, permissions and durable jobs.
 
-Cloud owns the REST backend, database, Kernel and hosted compute providers, recorder, evidence bundles, general privacy service, repair loop and credential storage. Cloud also owns Kernel CAPTCHA telemetry, antibot browser switching and proxy recovery notices.
+Cloud owns the REST backend, database, hosted browser and compute providers, recorder, evidence bundles, general privacy service, repair loop, credential storage and its own hosted authoring text.
 
 Integrations run through native Playwright. The local host does not mint HTTP variants, record network traffic, produce `captures/routes.json`, or provide the hosted `SiteHttp` transport and capture replay helpers. Website requests made inside the browser remain available.
 
@@ -229,6 +229,7 @@ The package exposes local APIs and direct core library entry points. Importing a
 - Use explicit `pomerado/core/*` subpaths such as `pomerado/core/mint/harness`, `pomerado/core/guardian/review` and `pomerado/core/runtime/host-execute` for hosted library composition. The export map lists supported modules.
 - Use `pomerado/testing/*` for reusable test helpers and fixtures. Vitest is an optional peer for helpers that need it.
 - Use `getAuthoringDirectory` and `getGuardianPolicyPath` from `pomerado/assets` for installed prompt and policy paths. These paths resolve relative to the package.
+- `loadAuthoringSkills` and `loadWorkspaceGuide` from `pomerado/core/mint/skills` render each named authoring section's standalone text by default. A host that supplies its own text for those sections composes the directory first, then loads it in `"hosted"` mode, which refuses any section left uncomposed.
 
 Run `corepack pnpm start --help` for the advanced terminal mint/run interface. Terminal mint retains its original source-artifact format. Use the MCP minting entrypoint for generated MCP packaging.
 
@@ -246,7 +247,7 @@ corepack pnpm test:browser
 
 This repository owns the portable tests for its shared core and local runtime, with synthetic fixtures and the existing Vitest and Playwright runners. Browser tests exercise native Playwright, minting through MCP, generated integration MCPs, authentication and autofill using local fixture sites and scripted model responses. They need no Cloud account or model API key. Tests for hosted services stay in the application repository.
 
-Outside pull requests are not accepted until a Contributor License Agreement is in place. Issues are welcome. See [CONTRIBUTING.md](CONTRIBUTING.md) for how changes land and [SECURITY.md](SECURITY.md) for reporting vulnerabilities privately.
+Outside pull requests are not accepted yet. They open once the review and approval gate described in [CONTRIBUTING.md](CONTRIBUTING.md) is live. Issues are welcome. See [CONTRIBUTING.md](CONTRIBUTING.md) for how changes land and how to report a vulnerability privately.
 
 Public tests use synthetic sites and data. Keep customer-specific incidents, private credentials and internal issue references out of public contributions. CI enforces this with a gitleaks secret scan and a public content scan. Run `node tools/check-public-content.ts` before you push. Link a public issue by its full URL.
 
@@ -258,6 +259,8 @@ The clone and build quickstart works independently of npm releases. Contributors
 
 ---
 
-Copyright (c) 2026 Pomerado. Licensed under GNU Affero General Public License version 3 only (`AGPL-3.0-only`). See [LICENSE](LICENSE).
+Copyright (c) 2026 Pomerado AI, Inc. Licensed under the MIT License (`MIT`). See [LICENSE](LICENSE).
+
+Versions 0.1.2 and earlier were published under the GNU Affero General Public License version 3 only (`AGPL-3.0-only`).
 
 Third-party code keeps its own license. The Guardian policy in `typescript/src/guardian/upstream-policy.md` is adapted from [OpenAI Codex](https://github.com/openai/codex) under the Apache License 2.0. Its license and notice are in [third-party/codex/](third-party/codex/) and ship with the npm package.

package/dist/typescript/authoring/auth/SKILL.md

@@ -15,12 +15,7 @@ or the data sits behind a login wall). Try a public task signed out first.
 
 # The login URL you record
 
-<!-- pomerado:hosted:start
-The `loginUrl` you pass on `authenticate` is published with the tool, and every run opens it to
-sign in. It must be a simple, stable route on the site: the page a person would bookmark to sign
-in, or where the site's own login link points before any redirect, read from that link. Never
-record:
-pomerado:hosted:end -->
+<!-- pomerado:section auth.login-url -->
 
 - a URL carrying one-time values: `state`, `nonce`, `code_challenge`, `code`, `session_state`,
   `SAMLRequest`, or a signed token or opaque random value in its query or fragment;
@@ -62,79 +57,20 @@ ask with `request_input` right away. A preselected option says nothing about the
 
 # One screen at a time
 
-<!-- pomerado:hosted:start
-Before recording, reopen the published stable `loginUrl` and map the complete signed-out flow. Reopen that
-route and record the required entry navigation from there, not just the username form reached
-after manual choices. Record each observed panel opener, authorized account/plan choice or
-Continue control as `signInStep: { fields: [], submit: "the-observed-selector" }`. Include only
-navigation needed for sign-in; exploration before the login URL and Business account actions,
-registration and password reset do not belong in the recipe.
-pomerado:hosted:end -->
+<!-- pomerado:section auth.signed-out-flow -->
 
 Record a field or submit only after observing its unique visible enabled match in the intended
 frame and form. Validate the complete live login and a fresh signed-out replay from the stable
 login URL. A saved DOM supports locator matching and extraction; it cannot prove live controls
 are actionable, their event handlers work or authentication succeeds.
 
-<!-- pomerado:hosted:start
-A run can begin partway through that flow because its bound profile or remembered device omitted
-an earlier stage. The host acts only on the observed recorded screen. It skips an earlier stage
-only when a later recorded page or distinct credential fields prove progression, or the published
-signed-in check verifies the session. A missing control, a timeout or a coincident Continue button
-on the same page does not prove an account choice happened. Record an authorized choice and its
-following Continue as separate steps.
-pomerado:hosted:end -->
+<!-- pomerado:section auth.partial-flow -->
 
 Call `execute` with purpose `authenticate`, target `liveBrowser` and a `signInStep` for the screen in
 front of you. Pass the stable route you clicked as `loginUrl` on the first one (above), never the
 page it redirected to; runs open that route to replay your screens.
 
-<!-- pomerado:hosted:start
-- `fields`: each field the screen asks for, as a Playwright selector with exactly one visible match.
-  A selector never reaches into another frame (no `>>` chains or `internal:` engines): the host finds
-  each field in its own frame.
-  - An identifier field lists every kind it accepts in `accepts`, from `username`, `email`,
-    `phone` and `account_number`: a "username or email" field is `["username", "email"]`, an
-    email-only field `["email"]`, a mobile-number field `["phone"]`, an account, member or customer
-    number field `["account_number"]`. Read the label, type and placeholder. The host sends a kind
-    the login holds (username first, then email, phone and account number) or asks the caller once
-    for one it accepts. If it refuses the step as `identifier_conflict`, the answer was not this login's: send
-    the step again to ask again.
-  - `slot: "password"` for the password.
-  - `slot: "code"` for a one-time or authenticator code. A saved authenticator seed answers it;
-    otherwise the host asks the caller for the code. Never ask for a code yourself.
-  - `slot: "date_of_birth"` for a date of birth, with `format`, how the field takes it, read from
-    its placeholder, label, input mask or hint: `MM/DD/YYYY`, `DD/MM/YYYY`, `M/D/YYYY`,
-    `D/M/YYYY`, `MM-DD-YYYY`, `DD-MM-YYYY`, `DD.MM.YYYY`, `YYYY-MM-DD`, `YYYY/MM/DD`, `MMDDYYYY`,
-    `DDMMYYYY` or `YYYYMMDD`. A native date input (`type="date"`) is `YYYY-MM-DD`. A date split into
-    a month, a day and a year is one field per part, each with its part's format: `MM` or `M` for a
-    month by number, `MMM` or `MMMM` for a month by its short or full name, `DD` or `D` for the day,
-    `YYYY` or `YY` for the year. A part may be a text box, a select or a custom dropdown: name the
-    select, or the dropdown's own control (its combobox or the button that opens its list), never
-    an option. The host fills the saved date into whatever control it finds, choosing the option
-    whose label or value matches, and records the format and the control's shape with the tool,
-    never the date. Every date layout, dropdowns included, is a screen you map.
-  - `slot: "zip"` for a ZIP or postal code the site checks to prove the account.
-  - `slot: "recovery_code"` for a backup or recovery code field. The host fills a saved one only
-    while recovery codes are the method in force, else asks the caller. Never ask for one yourself.
-- `submit`: the observed enabled control that submits those fields or advances this sign-in screen
-  ("Next", "Continue", "Sign in"). It may be a native button, a submit/button/image input, an HTML
-  anchor or a custom ARIA action: use its evidenced role, label or stable selector and purpose.
-  The host clicks it. A screen that advances by itself (the identifier fills and the password field
-  appears by itself) names none; unrelated links or buttons on that page do not need a submit.
-  A two-factor method choice ("Text me a code", "Use my authenticator app") fills no field: list
-  every method the screen offers in `methods` (`sms`, `call`, `email`, `totp`, `push` or
-  `recovery_code` for "use a backup code", each with
-  the selector of the control that picks it) and name the one to pick now as `submit`, once the
-  branch rule above settles which. The tool's runs pick again from that list. A method's selector
-  publishes with the tool, so it never names the masked phone number or address the option shows
-  (such as `***-1234`): use the method's own words or a stable attribute.
-- Every selector and submit you send publishes with the tool, as does each screen's page address.
-  None may name this account's username, email or phone: not a "Continue as …" button's text, a
-  data attribute holding it, or a placeholder for it. Name a control by its role, label or a stable
-  attribute. The host refuses a step that names it (`selector_names_contact`), and a screen whose
-  address names it (`page_names_contact`) is refused; use an account-independent route.
-pomerado:hosted:end -->
+<!-- pomerado:section auth.step-fields -->
 
 A screen may record `rejectedMarkers`, each with a field slot and an observed, value-free
 rejection selector. The slots are `username`, `email`, `phone`, `account_number`, `password`,
@@ -142,14 +78,7 @@ rejection selector. The slots are `username`, `email`, `phone`, `account_number`
 sign-in; never invent a marker or submit bad credentials to discover one. The host reads only
 visibility and retains every rejected value so it cannot send that value again.
 
-<!-- pomerado:hosted:start
-On a combined password-and-code screen that returns empty, an explicit code rejection permits a
-fresh code with the unchanged password only while its two-send allowance remains. When the
-password remains in its field, retry only the fresh code. In a recorded replay, missing or
-ambiguous evidence about which field was rejected requests maintenance without resending the
-password. Report a rejection visible in the current mint even if no selector has been recorded
-yet; a visible recorded marker takes precedence over that report.
-pomerado:hosted:end -->
+<!-- pomerado:section auth.code-rejection -->
 
 Guardian checks each step against the screen: that every field takes the kinds it lists, that the
 submit is the right sign-in action, including a fieldless continuation or verification-method
@@ -157,27 +86,9 @@ choice, and that a step without one advances by itself. The host checks that eac
 and visible and that its frame, form actions and link destination are on the site or a configured
 sign-in origin. A refused step typed and sent nothing and spends no sign-in: fix it from the evidence.
 
-<!-- pomerado:hosted:start
-Sign-in pages are often slow, and the next screen can take a while to show. Wait for its field with
-a bounded readiness wait (such as `locator.waitFor` with a timeout of about 30 seconds) before you
-map or fill it, and read the page again. Ask for a new browser with `request_browser_recovery` only
-after a reasonable wait still found nothing and the evidence points at the browser.
-pomerado:hosted:end -->
-
-<!-- pomerado:hosted:start
-After each step, read the next screen with a read-only `explore`. Never read, change or return a field
-the host filled, not even to check it. If the host reports that its click of the submit failed after
-the fields filled, you may click that one submit yourself in an `explore`, and nothing else; the host
-counts a value as sent only once it sees the form go out carrying it, whoever clicked. If it reports `submit: refused`, never click it.
-If the site says a field was wrong, send `signInStep: { rejected: { slot: "password" } }`
-with the actual rejected slot at once. The host asks for corrections; never ask for substitute
-credentials yourself or send a rejected value again. A primary identifier or password rejection
-asks for both username and password. A rejected secondary identifier, date of birth or ZIP asks
-only for that field; a recovery code uses the host's fresh-code ledger or question. The host allows
-at most two correction questions per rejected field per sign-in. Only submitted, visibly rejected
-fields consume their counters; `username` and the saved login's matching primary identifier share one
-counter. Worker takeover preserves these counters and rejected-value history.
-pomerado:hosted:end -->
+<!-- pomerado:section auth.slow-screens -->
+
+<!-- pomerado:section auth.next-screen -->
 
 A rejected code permits at most two fresh-code corrections within the remaining sign-in time.
 This does not extend the unchanged password's limit of two sends, including sends before worker
@@ -204,19 +115,11 @@ signed-in indicator; confirmation alone does not verify the session.
 
 # Signed in
 
-<!-- pomerado:hosted:start
-Prefer an observed protected business/account page or authenticated workflow control that the
-signed-out flow cannot reach, corroborated by the live business example. Generic Sign out or
-account chrome alone does not establish access to the caller's workflow. Call `authenticate`
-with `signInStep: { signedIn: { selector } }` (or `urlPath`, the observed signed-in page's path).
-When the landing page shows no such evidence, add `openPath`, the observed path of an account page
-that does, and the host opens it and checks there; never guess a protected route. The host checks
-that the submitted sign-in's recorded controls/form no longer show a password entry awaiting
-sign-in; unrelated password controls on the account page do not fail this check. It also checks
-that this sign-in submitted the login's identifier with its password, code or protected approval,
-then marks it verified; a Personal login locks to this site then. The indicator is part of the
-published tool: runs check it after they sign in. Business work waits for a verified sign-in.
-pomerado:hosted:end -->
+<!-- pomerado:section auth.signed-in-evidence:start
+Prefer an observed protected account page or authenticated workflow control that the signed-out
+flow cannot reach, corroborated by the live business example. Generic Sign out or account chrome
+alone does not establish access to the caller's workflow.
+pomerado:section auth.signed-in-evidence:end -->
 
 # Popup sign-in
 
@@ -239,29 +142,15 @@ browser. A failed host check leaves this browser available for another evidenced
 that sign-in could not be verified when the site or the remaining allowance prevents recovery.
 Never send a visibly rejected value again. There is no provider-login fallback.
 
-<!-- pomerado:hosted:start
-After browser recovery, inspect the retained bound profile before signing in. When its published
-signed-in indicator verifies the identity, continue without another credential submission. When
-it is signed out, sign in from the observed recorded stage on that profile, preserving what the
-site remembers; do not clear storage or log out merely to force the full flow. A genuinely empty
-profile starts the observed fresh sign-in flow.
-pomerado:hosted:end -->
+<!-- pomerado:section auth.after-recovery -->
 
 # Every sign-in ends with its check
 
-<!-- pomerado:hosted:start
-Every sign-in you record ends with a deterministic sign-in check, sent as `signInStep.signedIn`:
-a signed-in marker on the page the sign-in lands on (a selector, or the signed-in page's path), or,
-when that page shows none, an account page with `openPath` and the marker to check there. Choose a
-marker that every signed-in account shows and a signed-out page never does. Prefer an observed
-protected page or authenticated workflow control, corroborated by the live business example;
-generic Sign out or account chrome alone is insufficient. Never put an account's name, email or
-number in the marker: the check publishes with the tool and runs for every login, and the host
-refuses one that names this account. This strengthens the observed workflow evidence without
-adding a separate identity detector or guessing a protected route. The published
-tool records the check with its screens, and each run decides whether its sign-in worked by that
-check alone: a run whose check fails requests sign-in repair before its operation.
-pomerado:hosted:end -->
+<!-- pomerado:section auth.sign-in-check:start
+End every sign-in with a check that it worked: an observed signed-in marker that every
+signed-in account shows and a signed-out page never does. Never use an account's name, email or
+number as the marker.
+pomerado:section auth.sign-in-check:end -->
 
 ## A sign-in refusal found by operation code
 
@@ -273,34 +162,7 @@ The caller receives `credentials_rejected` and `rejected_field`; this requests n
 
 A direct sign-in request signs in with one host-filled HTTP request instead of an autofill form submission. Runs are faster with it, so the host prefers it once a mint proves it.
 
-<!-- pomerado:hosted:start
-1. From the explored login page, find what the form actually submits: its action, or the
-   request the page script sends (method, path, content type, field names, and any CSRF
-   field or header). Read the login page's HTML and scripts in the capture. Never submit
-   the form yourself. A staged form with a separate identifier submission is not a
-   single direct sign-in request. Omit this optional template and map the autofill screens.
-2. Author `src/website-auth-http.json`, for example:
-   `{"preload":"/login","request":{"method":"POST","url":"/api/login","headers":{"content-type":"application/json","x-csrf-token":"{{cookie.csrf_token}}"},"body":"{\"username\":\"{{identifier}}\",\"password\":\"{{password}}\"}"},"acceptedStatuses":[200]}`
-   - URLs are paths on the site, or an https URL on an approved sign-in origin. `preload`
-     loads a page first, so anti-bot and CSRF cookies are set before the request.
-   - It holds placeholders, never values: `{{identifier}}`, `{{password}}`, `{{code}}` (a
-     one-time code the host asks the user for), and `{{cookie.NAME}}` or `{{input.NAME}}`
-     for this sign-in's own CSRF values, read after the preload. The host fills them;
-     generated code never sees them. Never write a literal token or credential.
-   - If a vendor computes a per-request sensor payload in page JavaScript, a direct
-     request isn't possible. Omit the file.
-3. Call `execute` with purpose `authenticate`, target `liveBrowser` and the authored operation
-   entrypoint, without `signInStep`, to run this explicit host-filled template. The host validates
-   it before sending. An accepted status verifies the sign-in, and the receipt reports `method:
-"direct"`. A failure returns control without another credential submission. Inspect the
-   response and login page, then correct the template or use the evidenced autofill screens.
-   A visibly rejected password is corrected through the host; never resend it yourself.
-4. Publication includes the template only when this mint signed in with the same file and the
-   business example then completed. A registered run's failed direct request requests sign-in
-   repair before its operation. Until repaired, later calls use the verified autofill recipe.
-   The host manages the resulting session and tokens; callers never hold them.
-
-pomerado:hosted:end --><!-- pomerado:standalone:start
+<!-- pomerado:section auth.direct-request:start
 
 ## Standalone live authentication
 
@@ -310,4 +172,4 @@ Fields use the same slots and format declarations. `username` lists every accept
 
 Inspect each subsequent screen and send its observed step. A method or account choice needs caller input before selection. Wait for and verify an observed signed-in marker; disappearance of the login form is insufficient. Rejection requires caller correction and never authorizes replay of a private submission. Popup/frame sign-in uses the observed host target and configured sign-in origins, with the same destination guard.
 
-pomerado:standalone:end -->
+pomerado:section auth.direct-request:end -->

package/dist/typescript/authoring/caller-input/SKILL.md

@@ -13,64 +13,13 @@ Try first. Ask only for what the page or the caller uniquely knows at that point
 - a code the site sends during the action, such as a confirmation code by text or email;
 - a fact only the caller has that the site now asks for.
 
-<!-- pomerado:hosted:start
-Use a published input instead whenever the value is stable and the caller can supply it
-up front, such as a flight number, a date or a quantity. Never ask for a password, a
-username or any other login: the host asks for a login itself and signs in. Never ask
-for something the page shows, for permission to proceed with the operation the caller
-already asked for, or to solve a CAPTCHA.
-pomerado:hosted:end -->
+<!-- pomerado:section caller-input.published-input -->
 
 ## Declare, read, ask
 
-<!-- pomerado:hosted:start
-1. Declare every question the run may ask in the contract,
-   `defineOperation({ name, input, output, questions }, ...)`, by id, with its `type`
-   and a short `prompt`. The publication review reads these declarations once, so the
-   prompt names the choice or value, never a private value. Write `questions` as a plain
-   literal inside the entrypoint's own `defineOperation` call: during the build the host
-   reads it from that source, not from the running script, and a computed or imported
-   declaration declares nothing, so every question is refused as `Undeclared`. Each question
-   the example asks is also reviewed before the build's owner sees it.
-   - `{ type: "choice", prompt, allowOther? }`: one option; `allowOther` lets the caller
-     type their own answer, returned as `{ other }`. Own text that repeats exactly one
-     offered option's label (or its listed form entry, `id (label)`) returns that option.
-   - `{ type: "multi_choice", prompt, minSelections?, maxSelections? }`: several options,
-     at least one unless `minSelections` says otherwise, at most the options offered.
-   - `{ type: "text", prompt, maxLength? }`: free text.
-   - `{ type: "confirm", prompt, followUp? }`: yes or no, returned as `{ confirmed }`.
-   - `{ type: "secret", secretKind, prompt, maxLength? }`: a code the site sent
-     (`one_time_code`), an authenticator code (`totp`, which a saved login's TOTP fills
-     without asking) or other private text (`private_text`). It stays out of traces,
-     logs and the minting model. A secret you ask during the build with `request_input`
-     comes back to you as a handle such as `{{secret.s1}}`, which the host fills in only
-     when your explore, test or `act` source runs live, and only where it is the whole
-     string passed to `fill`, `type` or `pressSequentially` or a field of a request to this
-     site (core skill); the published script never holds a handle and asks for the value
-     with `ask` instead.
-2. For a choice, read the options in the execute call that reaches it and return them as
-   plain JSON. Each option has a `value` the script acts on and a `label` the caller
-   reads. Values are unique within a question. Offer only options the page will accept:
-   skip taken seats, disabled slots and sold-out items. The value never leaves the run;
-   the caller sees only the label.
-3. Mark an option taken from the caller's own account (a saved traveler, address, card
-   or account) with `accountSpecific: true` and a `maskedLabel` that keeps it
-   recognizable without its numbers or email, such as `"Jane D. •••• 7890"`. The API
-   and MCP show the masked label with a notice; only the owner's protected page shows
-   the full label. A masked label that still shows five or more digits or an email
-   address is replaced by the label's last four digits or a numbered placeholder.
-4. Ask once for everything the step needs, between two execute calls:
-   - `await ask("code")` returns that question's answer;
-   - `await ask(["seat", "note"])` returns one answer per id;
-   - `await ask({ seat: { options: seats }, code: {} })` passes a choice's options, and
-     nothing for the other types.
-pomerado:hosted:end -->
-
-<!-- pomerado:hosted:start
-   One ask takes up to eight questions, with up to 50 options per choice. A choice
-   returns the chosen `value`, a multi-choice an array of values. Write answers into
-   the next call's code with `JSON.stringify`.
-pomerado:hosted:end -->
+<!-- pomerado:section caller-input.declare -->
+
+<!-- pomerado:section caller-input.ask-limits -->
 
 The run waits with its browser open and its active budget stopped, and the next call
 starts on the same page. Continue from there. Do not reload, search again or repeat an
@@ -100,27 +49,17 @@ before the question is reported as a possible change when no answer comes.
 
 ## During a mint
 
-<!-- pomerado:hosted:start
-A read build's example run, or a write build's `act` step, asks the build's owner
-through the same request, and the answer comes back to the running script. Guardian
-reviews each question first. When it asks for a rewording, nobody is asked, the `ask`
-fails and the execution's result carries `scriptQuestion` with Guardian's rationale:
-change the declared question as it says and execute again. If the
-owner does not answer in time, the build ends as `no_response`; there is nothing to
-retry, and a write step after one that sent something is reported as a possible
-change. Do not turn an account-specific choice into a published input to work around
-a question.
-pomerado:hosted:end -->
+<!-- pomerado:section caller-input.during-mint -->
 
 `references/caller-choice.ts` books a seat on the caller's chosen flight: it asks for a
 seat and a saved traveler once the flight's seat map is shown, then books once and calls
 `verified({ confirmation: "message" })` after reading the confirmation back.
 `references/caller-code.ts` asks for the code the site sends to confirm an address
 change and enters it on the same page.
-<!-- pomerado:standalone:start
+<!-- pomerado:section caller-input.protected-answers:start
 
 ## Standalone protected answers
 
 Declare questions in the operation contract using the existing SDK schema and ask through `ask`. Ordinary answers are caller input, not extra authority. A `secret` answer is delivered privately for its declared purpose; during minting it returns an opaque handle. Use that handle only as a whole value at an authorized destination, never transformed, logged, returned, stored or read back. Website login credentials are requested only by the host during `authenticate`; TOTP/one-time codes are caller-supplied, with no stored seed automation.
 
-pomerado:standalone:end -->
+pomerado:section caller-input.protected-answers:end -->