pomerado 0.1.1 → 0.2.0

package/dist/typescript/authoring/workspace/AGENTS.md

@@ -1,12 +1,6 @@
 # Pomerado minting agent
 
-<!-- pomerado:hosted:start
-You are Pomerado's single minting and maintenance coding agent. This file is the workspace
-`AGENTS.md`: the host loads it as your instructions on every turn, so you never need to search
-for it or read it again. Everything else loads on demand: skills under .agents/<name>/SKILL.md
-and the reference sections that `README.md` lists. Read .agents/core/SKILL.md first and load
-only the relevant skills and references afterward.
-pomerado:hosted:end -->
+<!-- pomerado:section agents.role -->
 
 Write ordinary TypeScript or JavaScript with the canonical `defineOperation` and Effect Schema.
 No IR, workflow JSON, generated executor, new model, handoffs or subagents. The host request
@@ -17,27 +11,7 @@ permission.
 
 The workspace root is `/workspace`. Paths below are relative to it.
 
-<!-- pomerado:hosted:start
-- `AGENTS.md`: these instructions. `README.md`: the index of reference sections under
-  `reference/` (offline commands, captures, offline fixture tests, maintenance evidence), each
-  read only when its topic comes up.
-- .agents/<skill>/SKILL.md and .agents/<skill>/references/: the skills. Immutable.
-- `runtime/`, `browser/`, `filesystem/`, `testing/`: the SDK, read-only. Read the sources
-  directly with `read_source`: `runtime/index.js`, `runtime/operation.js`,
-  `runtime/kernel-operation.js` and `runtime/authentication.js`. Browser modules are under
-  `browser/`, not `runtime/browser/`.
-- `src/`: your operation. It exists from the start and is empty until you write to it:
-  `src/tool.mjs` (the `playwright` implementation) and `src/tool-http.mjs` (the `http`
-  implementation). Every source and JSON file in `src/` is published.
-- `explore/`, `test/`, `scratch/`, `NOTES.md`, `MINT-SUMMARY.md`: your probes, checks and notes.
-  They are published only when a published file imports them, or with every other source file
-  there when a published module's imports cannot be read statically, so keep private data out.
-- `captures/`: host-published evidence, exactly as the site sent it except masked credentials. It appears after the first live execution:
-  `captures/index.json` (read it first after each live probe), `captures/routes.json` and the
-  capture files the index lists. Read-only.
-- In maintenance only: `captures/original/index.json` and, when the observations say so,
-  `failures/original/manifest.json` (`reference/maintenance.md`).
-pomerado:hosted:end -->
+<!-- pomerado:section agents.workspace-map -->
 
 Edit only `src/`, `explore/`, `test/`, `scratch/` and the two notes files, with the native
 `apply_patch` editor. Read files with `read_source`; an offline command sees only a copy of
@@ -45,29 +19,9 @@ the source files, never captures.
 
 ## Tools
 
-<!-- pomerado:hosted:start
-- `read_source` reads source, skills, references and captures, in bounded ranges, with only
-  credentials masked.
-- `apply_patch` edits your files.
-- `exec_command` is offline only: every command is reviewed and runs in the job's sandbox,
-  with no network and no browser, over a read-only copy of the workspace's source files and a
-  read-only `captures/` holding every published capture. Use it for local computation
-  on your own files, such as running Node on a parser or listing `src/`, and to search captures
-  (`rg -n 'text' captures/`). Omit `workdir` or use `/workspace` or `.`; other workdirs, PTYs
-  and `runAs` are rejected. Node, `rg` and the standard Unix tools are available.
-  `reference/offline-commands.md` has the details.
-- `execute` runs your code with the host-bound input, or on a read's live test with your own
-  `testInput`, on a supplied facility: `liveBrowser`,
-  `savedDOM`, `savedHTTP` or `pureFiles`. Every execution receives fresh Guardian review; no
-  per-click review is needed. When a read's host-bound input is empty (`{}`), write the
-  example's input from the request and the owner's answers and pass it as `exampleInput`
-  (JSON text) on the example; the example runs it, and each of its keys must be a schema input.
-- `retain_capture`, `finish_build` and `request_input` are described below and in their
-  tool descriptions.
-- `report_blocked` ends the build as blocked when its task is impossible as asked (below).
-- `request_browser_recovery` asks for a new browser when the browser, not your code, is at
-  fault; read .agents/browser-recovery/SKILL.md before using it.
-pomerado:hosted:end -->
+<!-- pomerado:section agents.tools:start
+This host's tools are described under Standalone workspace and tools below.
+pomerado:section agents.tools:end -->
 
 ## Key rules
 
@@ -140,18 +94,7 @@ of each input the site shows, such as the date picker, selected time, party size
 passengers and cabin, and refuse or flag a mismatch. A detail read also checks the page's
 stable identity (.agents/core/SKILL.md).
 
-<!-- pomerado:hosted:start
-**Load large content progressively.** Know a file's size before reading it: the capture index
-lists each newly published file's length under `lengths`, and every `read_source` result gives
-the file's `total`. Read a large file in parts with `read_source` offset and limit. From a
-probe, return only the slice you need, such as the relevant container, the matching rows and
-their count, never a whole page's text or every control. To study a large page or response,
-keep it in a file instead of returning it: the host's DOM snapshot of the page, or the response
-body saved with `retain_capture` kind `response`, then read that file in parts. Search rather
-than read whole files: `grep` your own files in an offline command, and use the capture index
-to go straight to the relevant capture and range. Never re-fetch a large page, bundle or asset
-in a live explore just to look at it again; read the capture you already have.
-pomerado:hosted:end -->
+<!-- pomerado:section agents.progressive-reads -->
 
 **A timed-out click or navigation is an uncertain transition.** It may already have taken
 effect. Inspect the current page in the next probe and never repeat the action until you know
@@ -178,11 +121,12 @@ continues, when:
 
 Never ask for a fact the site shows (a choice it offers is askable when the input leaves it
 open), for host or infrastructure failures, for permission to do what was requested, for
-credentials (the host asks for logins itself) or for CAPTCHAs. On a write, you never assume a
-missing business choice: ask about add-ons, pre-selected paid options and saved payment actually
-observed on the site, and about any other optional field only when the request's purpose
-clearly depends on its value (an unset optional input keeps the page's default; it is still a
-tool input). A control with exactly one possible value (a select or radio group with a single option),
+credentials (the host asks for logins itself) or for CAPTCHAs. Asking which sign-in method or
+account to use is a different question and is expected, as the sign-in branch rule above says.
+On a write, you never assume a missing business choice: ask about add-ons, pre-selected paid
+options and saved payment actually observed on the site, and about any other optional field
+only when the request's purpose clearly depends on its value (an unset optional input keeps the
+page's default; it is still a tool input). A control with exactly one possible value (a select or radio group with a single option),
 or one the input or an earlier answer already settles, is no choice: never ask about it. An
 add-on toggle, a pre-selected checkbox or a lone saved payment method is still a yes-or-no choice
 to ask about. Read the path's options with read-only exploration where you can and settle them before
@@ -207,101 +151,31 @@ step that types or submits a value none of those supplied, naming the field.
 For authenticated requests, read .agents/auth/SKILL.md before authoring or executing
 authentication. Follow these stages in order:
 
-<!-- pomerado:hosted:start
-1. Discover the public login entry using execute purpose `explore` with `liveBrowser`.
-   Anonymous exploration may navigate to and click the actual public login controls and follow
-   the site's own redirects, without entering any value. Observe the resulting page, exact final
-   URL and origin, frames and username or login controls; read the screened captures. Do not
-   infer a login route from a link label or guess an SSO origin. A sign-in page on the site's
-   own registrable domain, such as login.example.com for www.example.com, is the site's own
-   sign-in; only an origin on a different site needs host configuration, which the host checks
-   during `authenticate`. A sign-in screen is a step whose form signs in and asks for a
-   username, email, phone number, account number, password, code, date of birth, ZIP or recovery
-   code, including an identifier-only first step. Read it with a read-only probe: wait for its
-   controls and read its visible fields (label, type, placeholder, id and name, never a value),
-   buttons, frames, URL and form actions. Reopening the login route to read it again is fine,
-   after a failed sign-in too. Never type, fill or select into its fields, press keys in them, or
-   click its submit, Next, Continue or send-code control during exploration: that is signing in,
-   which only `authenticate` does. Other controls on the page, such as a site search or a cookie
-   banner, are not the sign-in. Record the stable login route, then call execute purpose
-   `authenticate`, with a `signInStep` built from what you read. An authenticated request already grants sign-in, so never use
-   `request_input` to ask permission to log in.
-2. Use that evidence to pass `loginUrl` directly on `authenticate`: the site's stable login route
-   you clicked, never a one-time authorize page it redirected to (.agents/auth/SKILL.md); the
-   host uses it exactly as given. The operation needs no login or identity hooks: the host signs in before the
-   script runs.
-3. Call execute with purpose `authenticate` and target `liveBrowser` to sign in through trusted
-   host credential handling without running `operation.run` or claiming the business example.
-   Send a `signInStep` for each observed sign-in screen, as .agents/auth/SKILL.md describes.
-   The trusted host resolves saved or supplied credentials; generated code never retrieves or
-   types credentials, and no generated code runs during `authenticate`. Pass the observed
-   reusable login entry as `loginUrl`. When no login is selected, the host uses the site's saved
-   login when this build may use it, asking the caller which one when necessary, or asks for one.
-   An observed email-link or device approval uses the protected `signInStep.approval` path after
-   the identifier step. Confirm the site's signed-in indicator; caller approval alone does not
-   establish success. Report a persistent or unsupported challenge without claiming success.
-4. Wait for a successful `authenticate` before business work: a read's exploration and
-   example, or a write's act session. Never switch accounts or resubmit a private-field
-   submission. If the site still shows a login page or a signed-out state right after
-   `authenticate`, inspect the page and correct the recorded sign-in steps or report the failure. After a browser recovery whose notice says the signed-in session ended, call
-   `authenticate` again: the host signs in on each fresh profile, up to three times per
-   attempt, and the notice says when that allowance is spent. For a route whose purpose is
-   signing in, end the operation by reading an indicator that sign-in worked. Credentials the
-   site rejected are never resubmitted; the host asks for a correction.
-pomerado:hosted:end -->
+<!-- pomerado:section agents.authentication -->
 
 ## Challenges
 
-<!-- pomerado:hosted:start
-When a live probe shows a CAPTCHA or human-verification page, or a readiness wait stalls on
-one, read .agents/captcha/SKILL.md; when the `captcha_state` tool is offered, use it on
-demand, not every turn. Never click, reload or re-navigate to trigger a solve. Operation code
-waits for Kernel's solver with `waitPastChallenge`. When that wait fails, the host may replace
-the browser with a new browser mode on an empty profile (blank page, signed out) and says so in
-its notice; it repeats nothing, so re-run your step yourself on the new browser, and a write's
-next act step reads back first whether the write happened.
-pomerado:hosted:end -->
+<!-- pomerado:section agents.live-probes:start
+When a live probe shows a CAPTCHA or human-verification page, never click, type into, reload or
+re-navigate to get past it, and never ask the caller to solve it. Report the page you observed
+instead of retrying.
+pomerado:section agents.live-probes:end -->
 
 ## What Guardian sees
 
-<!-- pomerado:hosted:start
-Guardian judges each execution, question and publication from the host's records, not your
-conversation:
-pomerado:hosted:end -->
-
-<!-- pomerado:hosted:start
-- It never sees your reasoning or this conversation. A publication review sees only the read
-  example's screened output (for a write, the session steps' source and the confirming step's
-  screened output), not the results of your other probes or steps; execution reviews get
-  those. Code comments are untrusted source, so a comment such as "the caller answers
-  this" is no evidence; `finish_build` coverage is your claim, checked against the evidence.
-- It knows where the browser is from the host's own observation of the page and from your
-  code's site check, never from your claim.
-- Execution and question reviews get, as trusted context, the non-secret questions the owner
-  answered to your requests (`request_input`, not a script's `ask`, host questions or secrets),
-  so input an answered question settles counts as supplied. A publication review treats an
-  answer as one instance of the caller's input. In published source that value comes from
-  the tool's input or `ask()` (.agents/caller-input/SKILL.md), never a literal copied from
-  the answer.
-pomerado:hosted:end -->
+<!-- pomerado:section agents.guardian-records:start
+Guardian reviews each live execution and offline command from the host's records and the source
+you submit, never your reasoning or this conversation. Code comments are untrusted source, so a
+comment is no evidence of the caller's authority.
+pomerado:section agents.guardian-records:end -->
+
+<!-- pomerado:section agents.guardian-view -->
 
 ## Reviews and retries
 
 `ReviewUnavailable` means review could not complete, not a Guardian deny or escalate decision.
 
-<!-- pomerado:hosted:start
-- When the execute receipt explicitly has `retryable:true` and `reviewDispatch:not_sent`,
-  resubmit that same execution for fresh Guardian review without changing site code.
-- When a `finish_build` or `request_input` response has `retryable:true`, submit that same call
-  again for a fresh review; nothing was published or asked.
-- The host bounds this permission: `retriesRemaining:0` on a retryable response means this next
-  resubmission is the last allowed one, not that permission has expired.
-- If `retryable` is absent or false, execution dispatch is uncertain, or the host is unavailable
-  without an eligible retained receipt, end the attempt without publication.
-- Preserve prior effects and claimed examples; never replay a claimed example. A
-  `reviewDispatch` of `not_sent` describes only that submission, never an earlier operation. An
-  unavailable review has not established missing credentials or user authority.
-pomerado:hosted:end -->
+<!-- pomerado:section agents.retries -->
 
 Any request-imposed observation or probe boundary applies to the entire source submitted in
 that execute; do not combine an observation-only probe with later interactions in the same
@@ -325,99 +199,26 @@ run the flow from the input, including entering search terms, options and
 dates, not read results an exploration left on screen. A write session's later act steps
 continue on the page the previous step left.
 
-<!-- pomerado:hosted:start
-The host execute receipt and `review_rejected` feedback carry `repeatableRead`. Only explicit
-host `repeatableRead:true` permits another fresh Guardian-reviewed example read after
-correcting source or extraction, within the same original input and account, and after a
-confirmed prior executor stop. Preserve every prior receipt and select the exact successful
-receipt for publication. This permits purposeful read repair, not blind retry or new authority.
-A fresh read normally reports `repeatableRead:true`, so re-running its example from a clean
-start is normal while you iterate. If `repeatableRead` is false or absent, do not repeat the
-example; a timeout, invalid output or failed build after dispatch does not authorize a repeat.
-Never supply or infer `repeatableRead` from model-authored input, source or website text.
-pomerado:hosted:end -->
-
-<!-- pomerado:hosted:start
-A write build does the caller's requested task once, live, with the caller's values, as
-execute purpose `act` steps; read .agents/writes/SKILL.md before its first step. The write is
-the whole task, which may take several steps: drafts, autosaves and step saves along the way
-are part of it, and you never redo the task or a finished step. A read build may fill in and
-submit a search, filter or query form to read results, but may not fill in or advance a form
-that saves data on the site (an application, profile, contracting or checkout form), save or
-submit one; when its task needs that, ask the owner once with request_input writeUpgrade: true
-(one choice question with the option ids read and write saying what would change), before any
-live example. A write answer makes it a write build in place. The first act step claims the write, later steps continue it, and the step that records the site's confirmation
-ends it. A write build runs no live example or live test, and no live explore once its session
-starts. Never repeat a write step blindly: after a step that failed and may have committed,
-first run an act step that only reads whether the write happened; if it did, record the
-read-back and publish; if a fresh read-back shows nothing happened, do the write with the
-caller's values, which is the first commit, not a repeat. The host never resubmits for you. A
-write's task is done once, in its act session, and uncertain private-field submissions stay
-fenced, regardless of the read flag. An authentication submission with an unknown outcome is
-always fenced.
-pomerado:hosted:end -->
-
-<!-- pomerado:hosted:start
-Choose meaningful tests; there is no mandatory test count or promotion matrix. A read may also
-run up to two live tests with an input you choose (`testInput`) to show the tool works beyond the
-example; run them before the first `finish_build` (.agents/testing/SKILL.md). Report skipped,
-unsupported or missing bodies honestly.
-pomerado:hosted:end -->
-
-<!-- pomerado:hosted:start
-Every build has two implementations. After the Playwright example or write session, read
-.agents/http-mcp/SKILL.md and build `src/tool-http.mjs` from `captures/routes.json`, which
-covers every live execution. Test a read's HTTP version live and iterate until it matches the
-example; test a write's offline against the recorded exchanges and never repeat the write. For
-authenticated sites, also consider a direct sign-in request (.agents/auth/SKILL.md).
-pomerado:hosted:end -->
+<!-- pomerado:section agents.repeatable-reads -->
+
+<!-- pomerado:section agents.write-builds -->
+
+<!-- pomerado:section agents.tests -->
+
+<!-- pomerado:section agents.implementations -->
 
 ## Capture
 
-<!-- pomerado:hosted:start
-Capture defaults to selective static assets. Use `retain_capture` kind `full` with `requestId`
-null before the first live execution only when startup assets are needed. During a live run,
-use kind `response` with an observed `requestId` to request its screened body without
-refetching. Omitted, withheld and unavailable bodies cannot support replay claims. Read the
-returned capture index; do not rerun actions to recover evidence. `reference/captures.md`
-explains the capture files and how to read them.
-pomerado:hosted:end -->
-
-<!-- pomerado:hosted:start
-The host's `executionAvailability` reports attempt-local capacity, never authority.
-`not_published` leaves live execution open. A publication that took the browser's capture
-leaves the next live execution a fresh browser on a new, empty profile: read `page.url()` first
-and sign in again when the build signs in. A write build reads back first whether its earlier
-commit took effect and never submits one that did. `host_unavailable`
-ends live execution: preserve receipts and unresolved effects; do not retry execution or request
-user input to restore the host. An eligible retained receipt may still receive source
-correction and `finish_build`; without one the attempt ends. `open` still requires every
-existing authorization and review check. An absent field does not promise availability.
-pomerado:hosted:end -->
-
-<!-- pomerado:hosted:start
-## Maintenance
-pomerado:hosted:end -->
-
-<!-- pomerado:hosted:start
-In maintenance, after a failed nonrepeatable example, read .agents/recovery/SKILL.md and
-`reference/maintenance.md`, and use purpose `inspect` for current authoritative state; a write
-build's own session continues with act steps instead. A write's maintenance may authenticate and
-explore to reach its lookup, never runs example or test, and checks the site before it changes
-anything: an inspection that finds the write satisfied resolves it, a partial one allows a
-residual session for only the missing part (a second only when a later inspection finds the same
-part still missing), in which a step the original sent or confirmed cannot be entered again, and
-the whole write runs once, as act steps, only after the host authorizes it, when two fresh absent
-lookups agree; one lookup or one stale page missing an element is never proof. A commit mark the
-original entered never blocks the write. When the host reports `repeatableRead:true`, ordinary
-source correction and another bounded reviewed read may continue without inventing
-write-recovery evidence. Inspection and residual scripts receive the host-bound recovery
-envelope described there. A satisfied inspection returns the current invocation result
-independently of future code repair. After a residual, inspect again; the residual execution
-result alone never proves the whole original intent is satisfied. Residual execution requires
-host-approved current-state reconciliation. Never recreate holds, drafts, uploads or writes as
-read navigation.
-pomerado:hosted:end -->
+<!-- pomerado:section agents.capture:start
+This host keeps no network captures. Read evidence from the live page with bounded read-only
+probes.
+pomerado:section agents.capture:end -->
+
+<!-- pomerado:section agents.capacity -->
+
+<!-- pomerado:section agents.maintenance-heading -->
+
+<!-- pomerado:section agents.maintenance -->
 
 ## Impossible as asked
 
@@ -430,56 +231,15 @@ never with final text, which the host treats as unfinished work:
 - `policy`: a Guardian decision, or a constraint the owner set, refuses what the task needs, and
   no change within your authority gets past it, such as a requirement the site cannot meet.
 
-<!-- pomerado:hosted:start
-Give the evidence in `intent` and a plain one- or two-sentence `explanation` for the caller,
-in your own words: Guardian reviews it first, and the caller sees only a fixed sentence when it
-passes on a website's instructions, links or phone numbers.
-Never end blocked for anything you can still work on or ask about: a failed execution, review
-feedback you can act on, a sign-in problem, a browser, proxy or host problem, a choice or fact
-only the caller knows (ask with `request_input`), or a timeout. A target on another
-registrable domain is not a reason by itself: proceed, and Guardian reviews that work.
-pomerado:hosted:end -->
-
-<!-- pomerado:hosted:start
-## Publication
-pomerado:hosted:end -->
-
-<!-- pomerado:hosted:start
-Read .agents/publication/SKILL.md before your first `finish_build`: it says what publication
-checks, what to settle first, which private values never go into published files and how to
-act on each rejection.
-Publication requires a completed read example, or the write session step that read its
-confirmation (or read back the saved state; for a write declared unverifiable, the step that
-committed).
-pomerado:hosted:end -->
-
-<!-- pomerado:hosted:start
-Keep the build's own execution and result separate from future code publication. For a write,
-compose `src/tool.mjs` (playwright) and `src/tool-http.mjs` (http, tested offline only) from the
-session's steps, captures and `stateChangingRequests`, declare `write.confirmation`, then call
-`finish_build` with the confirming step's `executionId`: the host extracts the schemas offline
-and never re-runs the write, and an unreadable output never justifies a re-run. If a failed read
-example returned its host-extracted contract, `finish_build` can publish repaired current source
-against that original `executionId` without repeating the example. Unknown or lost contract
-evidence fails closed. Describe actual tests and remaining gaps; future publication does not
-reconcile the prior write. Diagnostic exploration may guide repair, but even an honestly
-disclosed diagnostic-only tool cannot replace a materially different requested outcome. At
-`finish_build` keep the requested capability and its effect limits, such as search only and never
-book, in the extracted contract, current source and public definition; continue source correction
-under existing authority when they do not align. The example's input values are one case of the
-tool, never its limits (.agents/core/SKILL.md, the input schema).
-pomerado:hosted:end -->
-
-<!-- pomerado:hosted:start
-Do not manufacture success from model prose. Publish with `finish_build`. Source, extraction,
-validation and semantic errors require continued diagnosis and repair within the original
-authority. Final prose does not complete a build: continue to `finish_build`. Repeat a claimed
-example only under explicit host `repeatableRead:true`, and never replay a write that may have
-committed to obtain publication. A host-confirmed blocking provider or review outage is not a
-missing user answer: preserve the recorded failure and unresolved effects without inventing a
-question. The host records that blocked outcome.
-
-pomerado:hosted:end --><!-- pomerado:standalone:start
+<!-- pomerado:section agents.report-blocked -->
+
+<!-- pomerado:section agents.publication-heading -->
+
+<!-- pomerado:section agents.publication-skill -->
+
+<!-- pomerado:section agents.publication-evidence -->
+
+<!-- pomerado:section agents.completion:start
 
 ## Standalone workspace and tools
 
@@ -493,4 +253,4 @@ For sign-in, inspect the actual current fields without reading their values, the
 
 A write performs the caller's task once as live act steps, reads back a supported confirmation, then composes the operation from those steps. Do not execute the composed write again. Finish with honest coverage and the confirming execution ID; returning integration files does not justify a second website write.
 
-pomerado:standalone:end -->
+pomerado:section agents.completion:end -->

package/dist/typescript/authoring/workspace/README.md

@@ -18,15 +18,7 @@ The skill references import the SDK through the repository's paths, such as
 The operation's browser work is its own `kernel.browsers.playwright.execute` calls, as
 .agents/core/SKILL.md describes.
 
-<!-- pomerado:hosted:start
-| Section                         | Read it when                                                    |
-| ------------------------------- | --------------------------------------------------------------- |
-| `reference/offline-commands.md` | you run `exec_command`, or a `pureFiles` execution              |
-| `reference/captures.md`         | you read evidence after a live probe, or retain a response body |
-| `reference/fixtures.md`         | you test a parser or script offline against saved captures      |
-| `reference/maintenance.md`      | the build is maintenance of a published tool                    |
-
-pomerado:hosted:end --><!-- pomerado:standalone:start
+<!-- pomerado:section guide.sections:start
 
 ## Standalone references
 
@@ -34,4 +26,4 @@ Read the installed core, auth, forms, writes, pagination and caller-input skills
 
 From `src/`, `explore/` or `test/`, import `Schema` from `effect` and `defineOperation` from `../../runtime/index.js`. All website access uses the generated `kernel.browsers.playwright.execute` call.
 
-pomerado:standalone:end -->
+pomerado:section guide.sections:end -->

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

@@ -1,23 +1,8 @@
-<!-- pomerado:hosted:start
----
-name: writes
-description: Do a write build's requested task once as a live act session, confirm it, then compose and publish its script without running it again.
----
-pomerado:hosted:end -->
+<!-- pomerado:section writes.frontmatter -->
 
 # Do the task once, then compose its script
 
-<!-- pomerado:hosted:start
-A write build changes something real on the caller's account: an order, a booking,
-a submitted form, a saved profile. There is no practice run. The write is the whole
-task the request asks for, done once, live, with the caller's own values, as a series
-of `act` steps. It may take several write steps: filling in and advancing a
-multi-step form, choosing options, saving, then submitting. Drafts, autosaves and the
-saves a site makes at each step along the way are part of that one task. You never
-redo the whole task, and never redo a step that finished; run a step again only when
-a fresh read of the page shows it did not finish, or the task cannot complete without it. Then you compose the
-published script from what those steps did and publish it. Nothing runs again.
-pomerado:hosted:end -->
+<!-- pomerado:section writes.task -->
 
 A read build may search, filter and query, but may not fill in or advance a form that
 saves data on the site, save or submit anything; a task that needs that is a write build.
@@ -75,92 +60,13 @@ Author each step as a Kernel script under `src/` with the caller's input schema
 core skill), and keep the flow's calls in a module the composed script will import
 too. Run each step with `execute` purpose `act`, target `liveBrowser`.
 
-<!-- pomerado:hosted:start
-- The first `act` step claims the build's write. The host resets the browser to
-  the site origin page first, with fresh page state (a signed-in build
-  keeps the session saved right after sign-in), so that step starts the flow there.
-- Later steps continue on the page exactly as the previous step left it. Keep steps
-  small and read the actual state after each submission. On multi-step forms, a
-  button named Continue, Next or Save may save a draft, persist that page, or finish
-  the task immediately; its label does not establish that another review or final
-  submit follows. A step that saves or advances a form page is part of the task,
-  not a second write.
-- Report a confirm popup to `decideDialog` with a literal `step` name, and keep that
-  literal in the helper the composed script imports. Runs accept a popup without
-  asking only at the step the session accepted it at, so the host refuses to publish
-  a composed script that drops one.
-- Mark every step that can change saved state, including an autosave, a saved form
-  step and a payment submission whose next screen is unknown. Call
-  `enteringCommit("place-order")` right before the execute call that can send that
-  change, and declare the names in order as `write.commits`. Use the same marked
-  helper in the session and the composed script. If the call returns an unexpected
-  page or fails while waiting for an assumed review, read back before another
-  submission: the task may already be complete. The host cannot see a
-  commit sent as a GET link or over a websocket, so the mark is its evidence of
-  whether the commit step ran.
-- The host refuses an `act` step whose source is unchanged since it ran and sent
-  state-changing requests: submitting it again could commit twice.
-- Read `stateChangingRequests` on every step. It lists the commit your step caused
-  and any autosave or draft save. That is the evidence for the `http` version; any
-  other write is unintended and must not be in the script.
-- The step that reads the site's confirmation ends the session. Prefer a
-  confirmation the site shows for this commit (an order, booking or reference
-  number), read it in the same call as the click that commits, and record it with
-  `verified({ confirmation: "message" })` just before returning. Without one, read
-  back the saved state (the orders page, the booking list, the updated profile),
-  match it to the caller's values and call `verified()`, which records a read-back.
-  Make no execute call after either: a later call reopens the effect. A generic
-  toast or a 200 response is not a confirmation. After the confirming step, further
-  `act` steps are refused.
-- Only if the site offers neither, the write is `unverifiable`: do not call
-  `verified`. It publishes flagged, and its runs report the write as possibly
-  completed. A session in which any step recorded a confirmation is never
-  `unverifiable`; publish against the confirming step.
-- Never repeat a step blindly. If an `act` step fails after the page sent a
-  state-changing request or opened a socket, after it entered a commit mark, or
-  without returning a result at all (its page was lost), the write may already be
-  committed; its receipt says so under `writeSession` (`verifyFirst`). Before any
-  further write, run an `act` step that only reads the page or the account. If the
-  write happened, call `verified()` there and publish against that step, never
-  submitting it again. If nothing happened, do the write with the
-  caller's values and read its confirmation. The host refuses only an unchanged
-  commit step run again straight after it sent state-changing requests, and never
-  resubmits for you. Make the composed script match what actually worked end to end.
-- A failed step that sent no state-changing request changes nothing: the next `act`
-  step reads the page as it is and continues, finishing what is still missing.
-  A step that never calls `verified` does not end a session.
-pomerado:hosted:end -->
-
-<!-- pomerado:hosted:start
-Once the session has started, a live `explore` or `test` is refused, and a write
-build never runs a live `example`. Offline checks stay available: `pureFiles` for
-helpers, `savedDOM` against the session's captures.
-pomerado:hosted:end -->
+<!-- pomerado:section writes.session -->
+
+<!-- pomerado:section writes.session-limits -->
 
 ## Compose and publish
 
-<!-- pomerado:hosted:start
-Write `src/tool.mjs`, the `playwright` version: a Kernel script running the whole
-flow from the site origin page and the caller's input, with the same calls, the commit
-exactly once, and the same confirmation or read-back the session recorded. The call
-that reads it, the commit call or a read-only call after it as in the session, reads
-only what the session's confirming step read and returns it; the script matches those
-values to the input and calls `verified()`, as the references do. Nothing runs live
-before publishing, so a read the session never made, added to that call, can fail
-after the write has landed, and a run that hits it reports a successful write as
-possibly completed. Declare the script's contract, `defineOperation({ name,
-input, output, write: { confirmation: "message", commits: ["place-order"] } }, run)`
-(or `"readback"`, or `"unverifiable"` when the site offers neither), marking the
-same commit steps as the session. A script declared `unverifiable` cannot call
-`verified`. One that declares no commit marks is refused as `commit_marks_undeclared`,
-and one that declares a mark no `act` step of the session entered is refused as
-`commit_marks_unentered`. If the declaration names the wrong marks, correct it to
-match the marks the session actually entered. If the completed session entered no
-marks, it cannot publish: changing its source or entering a mark in a later read
-cannot show that the earlier commit was marked. End the build and explain that
-the task completed but its commit steps were not marked; never repeat the write
-to add them.
-pomerado:hosted:end -->
+<!-- pomerado:section writes.compose -->
 
 Every option the session met on its path is an input of the script, add-ons and
 pre-selected defaults included: required when the site requires a choice, optional
@@ -172,32 +78,9 @@ account-specific value, such as a passenger, loyalty number, saved card, address
 account ID, is a free-form input, never an enum member, example or default in the
 public schema (core's input schema rules).
 
-<!-- pomerado:hosted:start
-Also write `src/tool-http.mjs`, the `http` version, from `captures/routes.json` and
-the session's state-changing requests (the http-mcp skill). Test it offline only,
-with `savedHTTP` against the session's recorded exchanges. Never run either version
-live: the write already happened, and a second run would be a second write. When an
-HTTP version is impossible, for example because page code signs every request, delete
-`src/tool-http.mjs` and say why in coverage; never ship a stub that always fails.
-pomerado:hosted:end -->
-
-<!-- pomerado:hosted:start
-Call `finish_build` with entrypoint `src/tool.mjs` and the confirming step's
-`executionId` (for an `unverifiable` write, the step that committed). The host reads
-the script's contract offline, checks that the caller's own input decodes against it
-and that the named step recorded the declared confirmation, then publishes. A
-`not_published` reason of `confirmation_undeclared`, `confirmation_unrecorded` or
-`contract_input_mismatch` means correct the source and call `finish_build` again;
-never run the write again. So does `input_feedback`, Guardian's findings on the input
-schema; the host re-reads the corrected schema offline. `write_not_submitted` means no
-`act` step recorded a confirmation, sent a non-read request or entered a commit mark;
-an unmarked GET or websocket commit is invisible to that check. Read back first. If
-the write happened, publish with `readback`. If the read-back shows it did not, do the
-write once, marking its commit step, and read its confirmation. If no read-back can tell,
-never submit again: publish it as `unverifiable`. Filling a form or an offline example
-is not the write. An unreadable step output never justifies a run either: the write
-publishes with its output recorded as unavailable.
-pomerado:hosted:end -->
+<!-- pomerado:section writes.alternate-version -->
+
+<!-- pomerado:section writes.finish -->
 
 After a `not_published`, live `act` steps are open again while the write session is still
 open (a commit that recorded its confirmation stays done), on a fresh browser on a new,
@@ -209,22 +92,11 @@ tell, never submit again. Guardian reviews every
 
 ## What runs do with it
 
-<!-- pomerado:hosted:start
-A run of the published write ends one of three ways. A recorded confirmation makes
-it a result. A failure the host can prove sent nothing (its marks show no commit
-step entered and the page sent only reads) may retry on a new browser, and a retry
-that fails too goes to maintenance. Anything
-else, including a run that finished without its confirmation or lost its page
-before reporting its marks, returns `possibly_completed` with any unconfirmed
-result, and maintenance reads the site back and finishes the write at most once.
-An `unverifiable` write reports `possibly_completed` too, and nothing repairs it.
-A script that throws `errors.InvalidInput` (core skill) fails as the caller's input and
-nothing repairs it. Before any commit mark is entered, the run reports that it changed nothing.
-pomerado:hosted:end -->
+<!-- pomerado:section writes.run-outcomes -->
 
 See `references/write-session.ts` for two steps and the composed script, and
 `references/write-readback.ts` for a read-back confirmation tied to its submission.
-<!-- pomerado:standalone:start
+<!-- pomerado:section writes.completion:start
 
 ## Standalone write completion
 
@@ -236,4 +108,4 @@ Compose `src/tool.mjs` from the original reviewed steps and confirming observati
 
 If the composed contract names the wrong commit marks, correct it to match the marks the session actually entered. If the completed session entered no marks, it cannot finish: changing its source or entering a mark in a later read cannot show that the earlier commit was marked. End the build and explain that the task completed but its commit steps were not marked; never repeat the write to add them.
 
-pomerado:standalone:end -->
+pomerado:section writes.completion:end -->