# Changelog

## Unreleased

### Breaking changes

- An unanswered question or the owner's no no longer ends a build as a `policy` block. `BuildBlocked`, `BlockedReport` and `JobBuildBlocked` add the reasons `owner_declined` (the owner answered no to a `confirm` question, or declined to sign in) and `question_unanswered` (a question the build needed came back as no answer). The host refuses each without its basis on record (`owner_not_declined`, `no_question_unanswered`), and a `policy` report whose only basis is one of them ends under that reason's name. `policy` now stands only on a Guardian refusal or on `MintDependencies.policyBlockAllowed`. A `MintHarnessSnapshot` whose `terminal.blocked` holds a new reason does not decode on a worker from an older release.
  - Migrate a host that maps each `blocked.reason` by handling the two new reasons.
- `BuildBlocked`, `BlockedReport`, `JobBuildBlocked` and `MintStopReason` add the reason `site_declined`: the site offers what the task needs but declines this example's own facts, such as an applicant it will not quote, and the explanation names the reason the site gave. Such a build used to end `site_lacks_capability`, which told its caller the site can't do the task. Like `site_lacks_capability`, it needs no basis on record, and Guardian reviews its explanation before a caller reads it. A `MintHarnessSnapshot` whose `terminal.blocked` holds it does not decode on a worker from an older release. The workspace guide and the `report_blocked` description name it.
  - Migrate a host that maps each `blocked.reason` by handling `site_declined`.
- `SignInStep`'s `rejected` may now be `{ account: "locked" | "suspended", selector }` beside `{ slot }`: the site showed, once the login was sent, that the account is locked or suspended, at the visible element `selector` names. The local host checks the element shows (`makeSignInRecorder` takes an optional `markerVisible`), then ends the sign-in with the new `SignInDiagnostic` code `AccountLocked` and its optional `account`, which leaves sign-in unavailable in the build. Migrate a host that reads `step.rejected.slot` by checking for `account` first, verifying the selector shows and failing the sign-in as `AccountLocked`.
- `TaskChange`'s `login` setting adds the change `signed_out`: once an update with it applies, the task runs signed out and the harness drops the unresolved sign-in. Migrate a host that maps each login change by handling it.
- `signInUnavailableSummary` words the owner's summary in plain language: it no longer names the root cause's code and phase or says that effects and receipts are preserved. The build's diagnostics keep the code and phase.
- A live example, a live test and a write session's first step keep the browser's cookies and site storage (local storage, IndexedDB, cache storage, service workers and the tab's session storage). The reset still closes other tabs, stops loading and returns the page to the site origin. A site that grants trust to a browser session keeps trusting it across resets. A browser where a sign-in started and none was verified still clears them, so a half-finished sign-in never reaches a step. Builds no longer save the session after sign-in or restore it before each reset.
  - `startStateFor` from `pomerado/core/runtime/start-state` takes `signInStarted` and `signInVerified` in place of `signedIn` and `sessionSaved`, and returns `keep`, `clear` or `none`. `restore` stays a `StartState`, `PageStart` and `resetPageCode` mode for a host's own resets, such as a run's retry. `shouldSaveSession` is removed.
  - `makeStartTracker` takes an optional `{ signInStartedBefore }`, for a browser that builds share, and tracks per browser whether a sign-in started or was verified. It adds `signInStarted`, `signedIn` and `browserReplaced()`, which a host calls when it replaces the browser, as for a new proxy: the new browser starts with an empty profile. `plan(step)` returns the `StartState` alone, in place of `{ save, start }`, and `save` and `saved` are removed. Migrate by calling `plan` for the reset mode and dropping the build-side session save.
  - `pomerado.hostProtocol` stays 1. No `./core/*` export is removed, and the reset and session-save helpers a host composes its own resets from (`resetPageCode`, `saveSessionCode`, `SavedSessionStorage`, `savedSessionStorageCapBytes`, `startPage` and `PageStart`) are unchanged. The changes inside `start-state` are to the build start rule and its tracker, which no known host imports yet; raising the protocol would make hosts that accept only protocol 1 refuse a package whose interface they use unchanged. A host that does call `startStateFor`, `makeStartTracker` or `shouldSaveSession` migrates as above.
  - The local host's `makeBuildStart` no longer exposes `saveSession`, and its signed-out sample hook runs after any reset before a sign-in started, as well as after a clearing one. `makeMarkerChecks`'s `afterClear` is now `afterSignedOutReset`. `makeLocalSessionSignIn` no longer takes `saveSession`.
  - A live test case keeps its browser's site data too. `LiveTestCaseRun` and `LiveTestRecord` in `pomerado/core/mint/live-tests` add the optional `start`, `warm` or `cold` (type and schema `LiveTestStart`): `cold` for a case that ran first on a new browser with an empty profile. The `LiveTestHost` contract asks a host with more than one browser to run at least one case cold and to mark every case it runs. The local host has one browser and marks every case `warm`. Each version in `publication/tests.json` adds `coldPasses`, the cases that passed cold on the published source, and the coverage line says how many passed cold.
  - Guardian's `publicationLiveTestsPolicy` treats a version with no case that passed cold as a gap for the rationale, never a finding, and no longer lists the example's rerun on a fresh browser as a gap that gets a finding. A recorded Guardian response keyed on the exact policy text needs recording again.
  - The core, testing, http-mcp, writes and auth skills, the workspace guide and the `live_tests` tool description say that examples and tests keep the browser's cookies and storage, so a script sets every value its input controls itself, and a case that runs cold is the proof.
- A filled `AutofillStepReport`'s `submit` may now be `page`: on a step with fields and no submit, once every field was typed, the page moved on before the host clicked anything, as a code widget that sends itself when its last box is filled does. `fillAutofillStep` reports it when its submit call finds the step's fields gone or all disabled, its popup closed, the page's address on another path than when the host typed the last field, or every field of a step of several emptied. Such a fill used to report `refused`, `none`, or its last field `failed` with `not_attempted`. The host gives the page its settle wait, at most 2 s, to move on before it reports `none`. A submit call that fails in that wait, as one does when the page navigates or draws itself again while the call reads it, is followed by another look: the fill reports `page` when a later look finds the page moved on, and the failed call (`uncertain`, `fill_call_failed`) as before when it does not. A step with a submit is unchanged: the host still clicks it, waits on a submit the page disabled, or refuses as before, whatever the page does while it checks what was typed. Guardian's refusals come first as before: a control that moved off the site or changed how it submits still refuses the submit.
  - `maySend` from `pomerado/core/destinations/autofill-refusal` is true for `page`, `fillFailure` in the run's sign-in replay passes it, so the sign-in's own check decides what the code did, a refused code included, and the minter reads its own notice for it.
  - Migrate a host that maps each `submit` value, such as to a notice or a failure, by handling `page` as a possible send that the sign-in's own check decides.
- A read signed out runs its live test cases as a batch on the HTTP version too, and each version keeps its own results: `live_tests` with entrypoint `src/tool-http.mjs` never replaces or stales the Playwright version's results, nor the reverse.
  - `LiveTestRecord` in `pomerado/core/mint/live-tests` adds the optional `entrypoint` the case ran. The harness keys results by case id and the entrypoint's version, from the new `liveTestVersion` (`http` for a `*-http.mjs` file, else `playwright`; type `LiveTestVersion`). A `MintHarnessSnapshot` from an older release, whose results name no entrypoint, restores them as the Playwright version's. `MintHarnessSnapshot` adds the optional `liveTestsHttp`, the HTTP version's results, while `liveTests` keeps only the Playwright version's. A worker from an older release drops the HTTP results rather than restoring them as the Playwright version's.
  - `liveTestsEvidence` takes `versions`, one `LiveTestVersionResults` (`version`, optional `entrypoint`, `sourceDigest`, `records`, optional `replaced`) for the Playwright version and one for the HTTP version when the build has one, in place of `records`, `replaced` and `sourceDigest`. Migrate by passing the Playwright version's former arguments as one entry with `version: "playwright"`.
  - The publication record `publication/tests.json` lists only the versions that ship: the published entrypoint's, and the HTTP version beside a published Playwright version unless `finish_build` ruled it out with `httpVersion`. A version that does not ship is neither recorded nor judged. The record adds `versions`, each version's entrypoint, source digest and counts, and gives each case `results` with its result on each version in place of the case's own status fields. Each retired entry names its `version`. Its top-level `sourceDigest` and `counts` move into `versions`. The coverage line counts each version on its own. `liveTestsEvidenceProblem`'s record adds an empty `versions`.
  - Guardian's `publicationLiveTestsPolicy` judges each version's coverage, and the HTTP version's parity with the Playwright version, from that version's own results. A case that passes on one version and fails on the other is a finding on the failing one. A recorded Guardian response keyed on the exact policy text needs recording again.
  - The testing, http-mcp and workspace guidance, and the execute and `live_tests` tool descriptions, tell a read signed out to run its cases as a batch on `src/tool-http.mjs` as well, instead of one input at a time.
- Test design is for reads signed out only. A signed-in read proves its tool with its example, and a write with its act session; neither designs further tests, runs extra live tests or builds offline test suites, and each checks its HTTP version once, against that run (a write by one `savedHTTP` replay of its session). A read signed out tests its HTTP version on several inputs, as it tests the Playwright version.
  - The scope follows what the tool is now, not what the build started as. A read that signs in or becomes a write mid-build, a repair included, has `live_tests` refused from then on and publishes with no test record. A repair that rebuilds a signed-in tool or a write as a read signed out gets the testing skill and parallel live tests. Guardian judges the published version's kind and this build's verified sign-in, not the original request's kind. Only a sign-in on the current site counts: after an update moves the build to another site, the harness, like the local host, no longer counts the earlier site's sign-in.
  - `preflightTestInput` from `pomerado/core/mint/step-checks` refuses every agent-chosen `testInput` unless `signedIn` is `false`. A signed-in read ran up to four before; a host that does not pass `signedIn` is now treated as signed in. The four-test limit and its count are gone, so `executionHistory` is optional and ignored, kept only so existing callers compile; it will be removed. Migrate by passing `signedIn: false` for a read that has not signed in, and dropping `executionHistory`.
  - The testing skill, its catalog description and the core skill, workspace guide, execute and `live_tests` tool descriptions, `testInput` description, http-mcp, writes, search, pagination and publication skills say so. The testing skill's note on reporting sign-in replay as unverified moves to the auth skill. A signed-in read's `live_tests` call and a write's live example or test are refused with an instruction to publish from the one run, no longer to test offline.
  - Guardian's `publicationLiveTestsPolicy` judges a signed-in read or a write on its one run alone: it never returns a finding, or asks for another run or test, because a capability was not tested beyond that run, and treats the coverage text's untested items as disclosure. A read signed out keeps its coverage judgment; when its host keeps no `publication/tests.json`, the policy now says to judge its coverage by the same rules from the coverage text, the live tests the execution context lists and the captures. A recorded Guardian response keyed on the exact policy text needs recording again.
- A list cursor works for ten minutes after the call that returned it, not the hour 0.4.0 canaries gave it: `listCursorTtlMs` is 600,000, `sealListOutput` dates `next_cursor_expires_at` ten minutes ahead, and `admitListCursor` refuses as `expired` a cursor past its own expiry or more than ten minutes (and five seconds for clock skew) past its issue, so a cursor a canary host signed for an hour stops working after ten minutes too. Migrate a host that describes the lifetime by saying ten minutes, and a caller that holds cursors longer by calling again without `cursor`.
- `pomerado/core/mint/live-tests` no longer exports `checklistOf`, `ChecklistItem`, `itemViews`, `ItemView`, `ItemStatus`, `repeatRuns` or `LiveTestSkip`, which 0.4.0 canaries shipped: the host derives no test checklist. A test case's `covers` is now `purpose`, and a cases file's `skipped` is now `notTested`. Migrate a canary host that read them by reading each case's `purpose` and the file's `notTested`.

- The local host stages beside authored source exactly the modules `pomerado/runtime` loads, plus `runtime/index.js`, and its own `node_modules/pomerado`, which exports only `./runtime`.
  - `privacy/*`, `runtime/browser-execution.js`, `runtime/capture-diagnostic.js`, `runtime/diagnostic-reasons.js`, `runtime/failure-detail.js` and `runtime/kernel-operation-validation.js` are no longer staged, and an import of the package's internal modules, such as `pomerado/core/runtime/operation`, no longer resolves for authored code. A saved integration that imported one fails to load.
  - Migrate such an integration by importing from `pomerado/runtime` or `../../runtime/index.js`.
- The `mint_update` refusal reason `maintenance` is now `maintenance_setting`, and maintenance adds `output_outside_maintenance` and `owner_unavailable`. Migrate by matching `maintenance_setting` where you matched `maintenance`.
- `ReviewTurn.missingRead` is now `ReviewTurn.followUp`, and `requiredReadRounds` is now `reviewFollowUpRounds`, three rounds: a reviewer sends the host's follow-up in the same review for an outcome the review's kind does not return, once, as well as for a skipped entrypoint read. `ReviewFailure` adds the code `InvalidOutcome` for an outcome still refused after that follow-up, which is not retried as an outage. A private host kind gets no follow-up and fails `InvalidOutcome` at once. `MintHarnessSnapshot` adds the optional `invalidOutcomes`, the attempt's count of such failures, which old and new workers each restore.
  - Migrate a host's own `Reviewer` by calling `turn.followUp` where it called `turn.missingRead`, for up to `reviewFollowUpRounds` rounds, and handle `InvalidOutcome` where it handles `InvalidDecision`.
- A review that returns an invalid outcome twice in a row in one attempt now ends the attempt as incomplete with no host failure, unless the host became unavailable, in which case the attempt ends with the host's failure instead. Diagnostics, including the `mint.execution_failed` event, now report `code: "InvalidOutcome"` for it. Migrate by not treating it as an outage: the first one comes back to the minter as the `mint_update` status `review_invalid_outcome`, now in `taskUpdateStatuses`.
- A maintenance `mint_update` output change may also `add` a field or `tighten` one (optional or nullable to required, or a narrower type), with no confirmation; a `remove` needs `reason`, or it is refused as `output_removal_reason` before review. `PendingTaskUpdate.maintenance.confirmer` may be `none`, for an update that only adds or tightens output fields. A host that compares a repair's output schema against an applied output change must ignore `add` and `tighten`, which loosen nothing.
- Guardian's execution review returns a required `action` label, `read`, `write` or `authentication`, in the shared output format. An execution allow without one fails to decode and is retried like an outage. An allowed `write` on a step without the new `PendingExecution.writeAuthority` becomes a denial.
  - Migrate recorded Guardian responses by adding `action` to every execution allow, and set `writeAuthority` on the steps that may write.
- `MintDependencies.reviewAndExecute`'s dispatch fence is a function of the allow it follows, so every dispatch carries a label: `beforeDispatch(allowed: AllowedExecution)`. Pass the review ID and Guardian's label, or `hostAuthentication` for a sign-in screen the host fills itself.
- The local host's blind-repeat guard and `replayedWriteStep`, `writeStepDigest` and `WriteStep` from `pomerado/core/mint/step-checks` are removed. The harness now refuses a step that repeats an earlier write's entrypoint until the outcome review finds that write did not happen.
- `sessionSentWrite` and `checkWriteSession` from `pomerado/core/mint/write-session` decide whether a write session sent its write from Guardian's labels and the outcome review, not from request counts or commit marks. They take `{ steps }` without `nonReadRequests`; each step carries its `action` label, `possiblySent` and its newest `assessment`. `write_not_submitted` means no step recorded a confirmation and no act step Guardian labelled a write may have reached the site, or the outcome review found each did not happen.
- The minter's prompts are one text for every host. These 33 named authoring sections are now shared text, so a host that composes its own text into the sections drops them. They are `core.example-input`, `core.schema-coverage`, `core.stale-session`, `core.testing-reference`, `core.completion`, `auth.login-url`, `auth.signed-out-flow`, `auth.partial-flow`, `auth.step-fields`, `auth.code-rejection`, `auth.next-screen`, `auth.signed-in-evidence`, `auth.sign-in-check`, `caller-input.declare`, `forms.saved-steps`, `pagination.no-recreated-writes`, `writes.session`, `writes.session-limits`, `writes.finish`, `writes.run-outcomes`, `publication.description-reader`, `publication.login-url`, `publication.confirm-steps`, `publication.input-feedback-end`, `publication.confirm-action`, `agents.workspace-map`, `agents.tools`, `agents.guardian-records`, `agents.guardian-view`, `agents.repeatable-reads`, `agents.write-builds`, `agents.tests` and `agents.capacity`. The other 69 sections stay. The new `core.standalone-completion` section ends the core skill with the local host's summary of its execution and completion, the text `core.completion` held before, so a host that composes its own text adds it. The new `writes.uncertain-status` and `writes.unverifiable-status` sections hold the status a run of a write reports when its outcome is uncertain, `may_have_applied` on the local host.
- `GuardianExecutionEnvironment` gains a required `dataVendor`. It holds the off-site rule's one exception, for the site's own third-party data vendor, and the evidence that shows it on that host. It follows the authorized-site rule in the execution policy. The local host's text says it keeps no network captures, so a request that carries the caller's input to another registrable domain escalates like any other caller data sent off-site.
  - Migrate by passing the exception your host can evidence. The exception 0.3.0 gave every host starts "The site's own third-party data vendor, such as a hosted search service, is the one exception" and relies on screened network captures.
- The package adds a `testing` skill, loaded after `auth`. Its sections `testing.offline-fixtures`, `testing.saved-targets`, `testing.capture-evidence` and `testing.later-cases` have no standalone text. A host that ships its own `testing/SKILL.md` drops it and composes its text into those sections instead.
- `saveSessionCode` from `pomerado/core/runtime/start-state` is now a function of the primary tab's target ID and the site's origin. Its browser call returns a `SavedSession`, `{ state, sessionStorage }`: the context's storage state, and the primary tab's session storage from its frames on the site's registrable domain.
  - Migrate by calling `saveSessionCode(targetId, siteOrigin)`, decoding its result with `SavedSession`, and passing that as the `session` of a `restore` `PageStart`.
- `resetPageCode` takes the primary origin, the site data, the session to restore and the tab storage to restore as separate arguments, then optional extra origins to clear, `cleanupOnly` and `keptCookiePrefixes`. Cookies whose names start with one of `keptCookiePrefixes` survive a clear. `PageStart`'s `restore` takes a `SavedSession`.
  - Migrate by calling `startPage`, which builds the call from a `PageStart`, or by passing the arguments in the new order.
- A sign-in through a security question is saved in `auth-fill.json` as recipe version 1, or version 2 with a popup or approval, with the question's selector on its field. It was version 3. This version still reads version 3 recipes, so nothing has to be built again.
  - 0.3.0 and every later version before this one, 0.4.0-canary.45 to 0.4.0-canary.47 included, refuse such a recipe. A run of an integration built this way fails there with `SignInRunFailed` (`MissingRecipe`, `invalid`) before it signs in or runs anything.
  - Migrate by running such an integration with this version or later, and not rolling back once one is built.
- A run reports a write that returned without recording its declared confirmation as possibly applied, not as a success. A write declared `unverifiable` reports the same. This holds for `run`, `pomerado run` and a served integration MCP.
  - A served write tool whose script declares no write and never calls `verified()` also fails as possibly applied. `pomerado run` is given no effect, so it still returns that script's output as a read.
  - `run` fails with the new `RunOutcomeFailure`. Its `outcome` has the code `outcome_unknown`, the write status `may_have_applied`, `possibleCommit: true` and the retry class `never`. Its `unconfirmed.output` keeps what the script returned.
  - Migrate by catching `RunOutcomeFailure` and reading the site back before any retry.
- Every other run failure that is not a sign-in failure also fails `run` with `RunOutcomeFailure`, including a failure before sign-in, such as the site check, the URL or the start page. Its `outcome` names a finite code, the write status, whether a step may have committed and a retry class. A sign-in failure still fails with `SignInRunFailed`.
  - A write's declared commit steps that were never entered show that nothing was applied only when the site refused the input or the login, or the run couldn't sign in again. Any other failure after a browser step ran may have changed the website.
  - Migrate by reading `outcome.code` in place of the operation's own error.
- A served run's failed job carries `code`, `write_status`, `possible_commit` and `retry`. Its `error` is one sentence for its code, and only a possible commit tells the caller to read the site back before any retry. The sentence that a dispatched action may have taken effect no longer follows every run failure.
  - Migrate by reading `possible_commit` and `retry` in place of parsing `error`.
- `pomerado run` prints an unconfirmed write's output on stdout and its outcome on stderr, and exits 1.
- The minter changes its task with the new `mint_update` tool once the caller confirms the change: input values, a requirement, constraint or prerequisite, the purpose, a read becoming a write, the target site or the login. It replaces the write upgrade and dropping a prerequisite on an answer alone.
  - Removed: `AgentRequest.writeUpgrade`, `MintDependencies.upgradeToWrite`, the `writeUpgrade` option of `MintDependencies.reviewQuestion` and `PendingQuestion.writeUpgrade`, `MintHarnessSnapshot.writeUpgradeDeclined`, `intentWithApproval` from `pomerado/core/mint/review-context` and `writeUpgradeApproval` from `pomerado/core/mint/step-checks`. An older checkpoint's `writeUpgradeDeclined` is dropped as an excess field.
  - Migrate by implementing `MintDependencies.reviewTaskUpdate` and `applyTaskUpdate`. `reviewTaskUpdate` runs `makeGuardian(...).reviewTaskUpdate` against the same pending review the host builds for any other review. `applyTaskUpdate` stores the harness checkpoint it is given (`TaskUpdateApplication.harness`, with the update applied) together with its own bindings, rebinds everything bound to the site for a site change, reruns intake screening and the duplicate check, and resolves the login, all or nothing. It answers `applied` for `next` exactly as given, or `clarification_required` or `refused`. A takeover that restored the checkpoint answers the same `mint_update` again as `updated` without another review, by the update's `requestDigest`. Without both hooks the minter isn't offered `mint_update`.
  - Every review after an update must carry `PendingExecution.taskUpdates`, with `allowedOrigins` rebound to a changed site, and each recorded execution its `taskRevision`. `MintHarnessSnapshot.purposes` entries carry an optional `taskRevision` too. `screenedIntent` is the intent as the owner submitted it.
- `mint_update` takes a `recommend` field, the minter's own judgment: `update` keeps the same task and workflow, and `new_mint` ends the build blocked with its `suggestedRequest`. Besides `updated`, `clarification_required`, `reword`, `new_mint_recommended` and `review_unavailable`, a result may be `update_refused`, when this build can't take the change (a site change while a write session is open or once the build can't run another live example, any change in maintenance, a recommended new build included, or a host refusal), or `update_invalid`, for a request that doesn't decode or a `new_mint` recommendation without a suggested request. Nothing changes on either. A site, login or effect change without an answer in `confirmedBy` is answered `clarification_required` before any review. After a site change, `finish_build` publishes only an execution that ran on the new site (`not_published` with reason `example_before_site_change` otherwise).
- A read build that already ran a live read example can become a write through a confirmed `mint_update`. The write session takes its own example claim, so `claimExample` is called again when its first act step starts, and `finish_build` publishes only what the write session did (`not_published` with reason `example_before_effect_change` for an execution from before the switch).
- An option the minting agent wrote is the owner's words once they pick it or type it back. `ownerNamedOrigins` now takes off-site origins from every answer, picked option labels and notes that repeat an option included, and Guardian's policy says so. `AnsweredQuestion.typed` is removed, and `answersForReview` keeps a note even when it repeats an offered option.
  - Migrate by dropping any use of `typed`. A decoder that ignores excess properties drops it from a stored answer; one that refuses them needs the field removed first.
- Guardian's shared output format adds the outcomes `clarify` and `new_mint`, for the new `update` review kind. `GuardianDiagnostics` correlations add the `update` review kind.
- `JobBuildBlocked` and `MintOutcome.blocked` add the reason `new_mint_recommended`, with an optional `suggestedRequest`.
- New exports: `TaskChange`, `TaskUpdateDecision`, `PendingTaskUpdate`, `ReviewedTaskUpdate` and `taskUpdateForReview` from `pomerado/core/guardian/task-update`; `TaskUpdateRequest`, `taskUpdateStatuses`, `TaskUpdateStatus`, `TaskState`, `AcceptedTaskUpdate`, `TaskUpdateCandidate`, `TaskUpdateApplication` and `TaskUpdateHostResult` from `pomerado/core/mint/contracts`.
- A local build's step asks only the questions its entrypoint declares as a plain literal in its one `defineOperation` call. The host reads them from the source, not from the running script. An ask whose id, prompt or bounds differ fails as `Undeclared` before Guardian's question review, and nobody is asked. A declaration held in a variable, imported or computed declares nothing.
  - Migrate by writing `questions` as an object literal inside the entrypoint's `defineOperation` call.
- A step whose literal `questions` names an invalid id is refused before review, with each id it names.
- A run asks only the questions publication reviewed. A published artifact keeps them as `questions`, an empty object when there are none, and `pomerado.json` saves them. An artifact saved by an earlier release has no `questions`, so it asks only what its entrypoint declares as a plain literal.
- A publication finding carries a required `explanation`: what is wrong, the evidence and the fix, at most 800 characters. Guardian's output format requires it, and a decision whose finding has none fails as `InvalidDecision`. `finish_build` returns each finding's screened explanation and its workspace `file` beside Guardian's `path`, and tells the minter to fix every finding and call again.
  - Migrate by adding `explanation` to every `PublicationFinding` a host makes itself, and to a host's own publication decoder.
- `example_value` is no longer an input finding. An input narrowed to the example's value blocks publication with reason `source_correction`; a decision that returns it as `input_feedback` fails as `InvalidDecision`.
  - Migrate a host's own publication policy by listing only `account_specific_enum` and `input_option` under `input_feedback`.
- A publication finding in Guardian's shared output format carries `quote`, the exact text at fault, in place of `byteStart` and `byteEnd`. The host finds the quote's UTF-8 range in the file Guardian read, first exactly, then with any run of whitespace standing for another. A quote the file does not hold, or a file the host cannot read, puts the finding on the whole file, and the denial stands. The decoded `PublicationFinding` still carries `byteStart` and `byteEnd`, and a reviewer that returns a byte range keeps it.
  - Migrate recorded Guardian publication responses by replacing each finding's byte range with its quote. A host's own publication policy should ask for a quote; core exports its wording as `publicationDecisionPolicy`.
- Guardian's `read_source` tool takes a required `match`, null for a plain read. With a word or phrase, it returns `untrusted_source_matches`: the slices of the whole file around each case-insensitive occurrence, up to 20, each with its byte offset, and the match count. Guardian queries a capture or other large file this way instead of reading it whole. `publicationCaptureQueryPolicy` is the policy's wording for it.
  - Migrate recorded `read_source` calls by adding `"match": null`. A call without it still reads a chunk.
- The authored runtime's `browser/index.js` now imports `browser/outcome-wait.js`. Until hosts compute the SDK's file list from its imports, a host that copies a hand-kept list of the SDK's files into a minting workspace or a run's sandbox must copy it too, or every authored operation fails to load.
  - Migrate by adding `browser/outcome-wait` beside `browser/form-controls` in that list.
- Guardian's publication findings add the category `safety_default`: a safety default that an earlier copy of the source set and the current source drops or weakens. It blocks publication with reason `privacy`, and Guardian's shared output format lists it. A build's `publicationDenial` and a `MintHarnessSnapshot` can carry it, and an earlier version doesn't decode either one that does.
  - Migrate a host's own publication decoder by accepting the category, and a host's own publication policy by including `publicationSafetyDefaultPolicy` (see Other changes).
- Run outcomes add the code `input_not_applied`, retry class `same_key`, so a host's `FailureRenderer` must word it. A script throws the new `errors.InputNotApplied(message, { field, requested, applied?, step, siteMessage? })` when the page did not apply a valid value the caller supplied, such as a location, store, filter, sort or date it ignored, reset or replaced with its own. The runner code is `InputNotApplied`. The run fails rather than return results computed without the caller's value, and the outcome's details carry `field`, `requested`, `applied`, `step`, `site_message` and the script's `reason`. Only a read or a run that left the site untouched gets it: a write that may have changed the site keeps `outcome_unknown`, a confirmed write `execution_failed`, and so does a run that judged a step may have committed. A numeric part, such as a ZIP code typed as a number, is kept as its text. `RunEvidence` gains `unapplied_input`, and `pomerado/core/runtime/operation-failure` exports `boundedInputDetail`, `InputNotAppliedDetail` and `maximumSiteMessageLength`.
  - 0.4.0 canaries shipped this for locations only, as `errors.LocationNotApplied`, the code `location_not_applied`, the runner code `LocationNotApplied`, the error's and the local protocol's `location` detail, `RunEvidence.location` (`RunLocationEvidence`), `boundedLocationDetail`, `LocationNotAppliedDetail` and `maximumLocationMessageLength`. `errors.LocationNotApplied` stays as a deprecated alias of `errors.InputNotApplied`, the same class, so a published tool that throws it keeps running and now ends `input_not_applied`. The classifier still reads a record's `failure_reason` of `location_not_applied`, and its `location` detail when it has no `unapplied_input`, and reports it as `input_not_applied`; `runOutcomeCodes` no longer lists `location_not_applied`. The live tests still pass a case that expects `error` on the runner code `LocationNotApplied`, which an older runtime reports, and `finiteRunnerErrorCode` still keeps it.
  - Migrate a canary host's renderer by wording `input_not_applied` in place of `location_not_applied`, its record of a run by passing `unapplied_input` where it passed `location`, and a hosted runner by passing `InputNotApplied` and the error's `unapplied` detail through as it passes `InvalidInput` and its refusal. A host that stores the failure reason should accept `input_not_applied` before any runner reports it, and keep reading `location_not_applied` for records and runners from earlier releases. A tool minted with `InputNotApplied` fails as an ordinary script error on a runtime from before this change, so upgrade a host's runners before its minter.
- `waitForOutcome` (in `outcomeWaitCode` and `waitCode` from `pomerado/runtime`) now fails as `outcome_unknown` once the page shows none of its outcomes and no progress for `noProgressMs`, 8 s by default, where it used to wait out its whole `timeout`. A slow page with no sign the wait recognizes, or whose API is on another registrable domain, can now fail before its `timeout`.
  - Migrate code that relied on waiting out a long `timeout` by passing `noProgressMs` equal to that `timeout`, or by naming the site's loading sign as `loading` and the part of the page the answer appears in as `region`.
- A minter's question left unanswered no longer ends the build. `request_input` returns `no_answer` when nobody answers before the question expires, and the minter decides how to go on: with a sensible default it lists in its `finish_build` assumptions, a narrower tool, or `report_blocked`. No answer is never consent, so a `mint_update` whose `confirmedBy` names that question is refused as `clarification_required`. The read-or-write question, the capability question, any question in a write repair and any question asked while the build is signed in or holds a login still end the build as `no_response`, and so does an unanswered sign-in request. Each question is decided when it goes unanswered: the build is signed in or holds a login once the host has one bound (`websiteCredentialsAvailable`), `requestLogin` answered `supplied` or `held`, or a sign-in in the build sent one, so a build that starts signed out hands back its earlier questions and ends on one asked after it signs in. The checkpoint keeps an obtained login as the optional `loginHeld`; a checkpoint written before it existed doesn't record a login obtained through `requestLogin`, so a build restored from one counts that login only once a sign-in in the build sends it. A host with no caller to ask hands the question back the same way, by failing its `askInput` with `noResponse`; the local host now does so when its caller leaves the minter's question unanswered, where it used to report the question as not asked. An owner's cancel, such as Ctrl-C at the terminal, is a choice to stop: a host marks it with the new optional `MintFailure` field `ownerCancelled` beside `noResponse`, and the build ends as `no_response` without handing the question back. The local host marks the terminal's cancel this way.
  - At most two unanswered questions, the minter's own and its scripts' together, go back to the minter in one build; the next one left unanswered ends the build as `no_response`. The count is kept in the harness checkpoint as the optional `noAnswerHandBacks`.
  - Once a question went back unanswered, `report_blocked` with reason `policy` ends the build, so the minter can stop instead of going on past what it asked.
  - An example or `act` step whose script question goes unanswered no longer ends the build either: its result carries `scriptQuestion` with the new outcome `unanswered` and an instruction, outside a write repair and a build that is signed in or holds a login when the question goes unanswered. `ScriptQuestionOutcome` gains that variant, whose `requestId` is optional.
  - Migrate a host that handles `ScriptQuestionOutcome` exhaustively by adding `unanswered`, and a host that waited for `no_response` to end a build after an unanswered question by reading the build's own ending instead.
- A Guardian review no longer has a deadline, so a review that ran past it is no longer started again from scratch, repeating all its work. A slow review runs to its decision. It is bounded three ways instead, and none of them starts the review over:
  - Its turn limit, 12 turns by default and 32 for the core publication review, now ends in one more turn that offers no source read, with a note to decide from the evidence already in view. The review returns that decision. Only a review that still returns none fails `TurnLimitExceeded`.
  - Each model call has its own bound. A call with no response for five minutes is aborted and sent again with the same input, at most twice, while the review's reads and earlier calls stand. Each such retry emits `guardian.model_call_retried` with `attempt` and `timeoutMs`. A call that stalls every time fails the review with the new `ReviewFailure` code `ModelCallStalled`. The bound is `guardianModelCallBound` (`{ timeoutMs, retries }`, type `GuardianModelCallBound`) from `pomerado/core/guardian/model`, and a host can set its own through the new `modelCallBound` in `GuardianModelOptions`.
  - The outage retry still runs a new attempt after a provider error, a decision that does not decode or a required source read that failed. Its `budget` now counts from the first failed attempt, not from the start of the review, which no longer has a deadline, so a long review that then meets a provider error is still retried. `TurnLimitExceeded` and `ModelCallStalled` are no longer outages: `guardianOutageRetry` returns them at once rather than starting the review again.
  - `ReviewFailure`'s `reviewPhase` no longer has `review_deadline`, which nothing produces now. `guardianReviewTimeout` is deprecated and nothing reads it; it stays so a host that imports it still loads, and will be removed. The second argument of `makeOpenAIReviewer`, `developmentPublicRead`, chose a longer deadline and no longer has an effect; it stays so callers compile.
  - `pomerado.hostProtocol` stays 1: no `./core/*` export is removed. Migrate a host that matched `reviewPhase` `review_deadline` by dropping that case, a host that maps each `ReviewFailure` code by adding `ModelCallStalled` as a review that could not finish, and a host that bounded reviews with its own timer around a review by relying on the per-call bound instead. A host that wraps the reviewer with `guardianOutageRetry` needs no change.

- `errors.InvalidInput` keeps an explicitly empty list beside the field it names: `new errors.InvalidInput(message, { field, available: [] })` now carries `available: []`, which says the page offers nothing for that input, so a host that repairs can settle it as it settles a refusal with choices. A missing `available`, an empty list beside no field and a list of blank labels still carry none. `boundedRefusalDetail`, the local operation protocol and the local host's `input_rejected` outcome are unchanged: they carry only a list with at least one choice.
  - Migrate a host that reads the error's `available` by checking its length, not only that it is present: an empty array means the page offers no choice, not a list to show the caller.

### Other changes

- `inspectAutofillStep` in `pomerado/core/destinations/autofill-step` takes an optional `trustSignInUrl(url: URL): boolean`, a host's own trust of more sign-in addresses, for a host whose user allowed a sign-in to go wherever the site sends it. Core asks it about each address of a sign-in step's fields, submit and popup that is neither on the site nor an `authenticationOrigins` entry, and only about one core would let a host trust: an https address with no user name or password, on a host with a registrable domain under a listed public suffix. Plain http, IP addresses, localhost, bare public suffixes, names only a private network resolves (under .localhost, .internal, .local, .test or .invalid) and hosts under .arpa or .onion stay refused, and the host is never asked about them. A card-fill step, and every part of a payment card, never use it. The inspection keeps the predicate as `trustSignInUrl`, and `fillAutofillStep` asks it again about a control that moved. Since it is also asked after typing, about addresses the page shaped, the host must never log, keep or forward a URL it is asked about. A predicate that throws trusts nothing. Refusal evidence names origins as before, so once anything was typed an origin no inspection judged is still named `other`. Unset, every check and every inspection is the same as before. `untrustedTarget`'s trust takes the same optional field.
- The cart skill's refusal of an order the site refuses as asked, such as one under its minimum, names the input: `new errors.InvalidInput(message, { field })`, `field` the input the caller would change.
- A write finishes every check that can refuse before its commit mark. The writes, cart, caller-input, core and publication skills and the workspace guide say that choosing a price-changing option, deciding an add-on or offer, reading the total and comparing it with a limit the input sets, and checking availability, the items, the address and the payment all happen before `enteringCommit`; the marked call only re-reads what a change would make wrong, clicks once and confirms. A refusal throws `InvalidInput` before the mark with `field`, a stable `kind` such as `over_price_limit` and the observed values in its message, so the run reports that it changed nothing. A refusal returned as output, or thrown after the mark, reports a possible change. A check that can only run after an earlier marked step runs before the later step's mark, and its refusal reports a possible change. The `write-session.ts` reference now checks its total against an optional `max_total_minor` input before its mark and guards the total inside the marked call.
  - A paid add-on or pre-selected paid option within the tool's purpose, the payment method and the delivery address are inputs or run-time questions. A checkout never uses the page's pre-selected address or payment silently, and never hard-codes a choice the build's request or the owner's answers settled, since the published tool serves other callers. A paid upsell outside the tool's purpose, such as a membership offered at checkout, is declined without a question and never accepted without an input the caller set.
  - The forms skill tells conditional pop-ups (shown only for some accounts, states or visits, such as a promotion or a membership upsell) from ones an action always opens: a conditional one is handled when it shows and never waited for or required. The `write-session.ts` reference declines a membership offer only some accounts get.
  - Guardian's publication policy adds a confirmation finding for a check that can refuse made inside or after the marked call of the commit it guards, or a refusal returned as output (a re-read that stops before the click, and a check after an earlier marked step, are no finding), and a source-correction finding for code that requires a conditional pop-up. Its `input_option` finding covers the payment method, the delivery address and a hard-coded build-time choice, and names what is no finding: declining an out-of-scope upsell, a safety default, and dismissing a dialog with no paid or private choice. Guardian's execution review treats declining an out-of-scope paid upsell, or dismissing a dialog with no paid or private choice, as no missing input, so a live write step that does either is not escalated. A recorded Guardian response keyed on the exact policy text needs recording again.
- Guardian's review of a blocked explanation reads a decision ledger the harness writes, so it judges the report against what the build's reviews decided and its live tests showed, not against what its own compacted conversation still holds. `reviewQuestion` receives the optional `decisionLedger` (type `DecisionLedger` in `pomerado/core/mint/contracts`) for a blocked explanation, and Guardian reads it as `question_review.decisionLedger`.
  - The ledger lists each Guardian denial or escalation of an execution, a live test batch or a publication in the build, with its outcome, reason, review id and the rationale and finding explanations Guardian wrote, screened as they are for the minter. It counts each live test case's latest verdict and lists the cases whose latest result did not pass. A failing case's error class and message sit under `toolReported`: they are what the agent's own tool code threw, and the policy says they show how the tool failed, never why the site behaved as it did. Only the denials, their review ids, the verdicts and the counts are host facts.
  - It keeps the latest 12 denials and 20 failing cases, caps each rationale at 800 characters, each of up to 4 finding explanations at 300, each message at 300 and each error class and result at 120, and counts what the bounds left out (`omittedDenials`, `omittedFindings`, `omittedTestFailures`).
  - `MintHarnessSnapshot` adds the optional `decisionLedger`, the denials so far, so a takeover keeps them. An attempt that restores a checkpoint without it, from an older worker, marks its ledger `partial`, and the policy says a denial missing from a partial ledger proves nothing. An older worker ignores the field.
  - `PendingQuestion` and `questionForReview` add the optional `decisionLedger`. A host that builds its `PendingQuestion` from named fields forwards `decisionLedger` to give its blocked reviews the ledger; one that does not keeps today's review. A recorded Guardian response keyed on the exact policy text needs recording again.
- Guardian's `read_source` tool reads up to 10 files in one call: with `path`, `offset` and `match` null, `paths` lists each file with its own `offset` and `match`. The result, `{ kind: "untrusted_sources", files }`, holds each file's chunk or matches in order; a file that cannot be read has its own `status: "unavailable"` entry and the others still return. Once a call's results reach 200,000 characters, its remaining files come back `not_read` for another call. Each file is its own read through the host's `readSource`, so it counts as Guardian's read for the entrypoint check, the publication round's whole-file reads and a session's unchanged sources, as a call naming only it would. A single-file call is unchanged, and a recorded call without `paths` still decodes.
  - The instructions every review kind shares ask Guardian to request the files it already knows it needs in as few calls as possible, up to 10 files each, and to read again only for files or chunks those calls show it needs; the core publication policy says the same.
  - A call the host cannot read, such as one naming more than 10 files or setting both `path` and `paths`, reads nothing and tells Guardian what to change, such as to split the files over several calls, instead of reporting the source unavailable. A recorded Guardian response keyed on the exact instructions or tool schema needs recording again.
  - `pomerado.hostProtocol` stays 1: no `./core/*` export changes, and a host's `readSource` serves each file as before.

- `lintSchemas(inputSchema, outputSchema)` in `pomerado/core/runtime/output-lint` adds two advisory checks of a tool's declared schemas, never of its values: `loose_text`, a required output string whose schema accepts an empty string or whitespace alone, and `looser_than_input`, an output field looser than the only input field of the same name (an enum dropped or widened, a format's pattern, one that refuses plain words, neither repeated nor replaced by an enum, a smaller `minLength`, or optional or nullable where the input is required). Neither blocks. A schema that refers to itself is walked once per definition, and a walk records at most 2,000 fields. `outputChecks` and `outputCheckMeaning` list both. `lintOutput` never reports them, so a run's output checks and telemetry are unchanged.
  - `outputNotes` from `pomerado/core/mint/output-notes` takes an optional `inputSchema` and adds these findings to `publication/output-notes.json`. The local host passes it at publication, and adds the findings to an example's output-check notice for the minter.
  - Guardian's `publicationOutputNotesPolicy` reads them as leads for the Loosened needed value rule, on needed values only. The rule itself now asks for every needed value's field to be judged in one pass, required, not nullable, non-empty and not whitespace alone, its format held by a pattern where it has one, and no looser than the input it reports, and a later review of the same build to judge what changed.
  - The core skill asks for inputs and outputs typed as strictly as their values, with `Schema.NonEmptyTrimmedString` for required output text and `Schema.NonEmptyString.pipe(Schema.pattern(/\S/u))` for required input text, which still takes a caller's stray space, a pattern for a date, time or code, and an output that reports an input's value reusing that input's enum or pattern.
- Guardian's publication review quotes a line or two of the text at fault without hunting for a unique quote: the host already places a quote at its first occurrence, or on the whole file, and the finding stands either way.
- Guardian's publication policy adds `publicationReferencePolicy`: the SDK's behavior is in `pomerado/browser/index.js` and `pomerado/runtime/*.js` and the minter's skills in `.agents/<name>/SKILL.md`, which the reviewer may read on demand where the host serves them; a path the host does not serve is not missing evidence. The local host serves the SDK's modules under `pomerado/`, a `.ts` or `.d.ts` spelling as the same-named `.js`, and its skills to the publication review through the new optional `references` of `PublicationReview` and `PublicationCandidate` in `pomerado/core/mint/publication-review`, which stay out of the publication index. `skillReferenceFiles` in `pomerado/core/mint/skills` lists a host's skills at those paths. A recorded Guardian response keyed on the exact policy text needs recording again.
- A host can choose Guardian's reasoning effort for each review. `specialize` in `GuardianModelOptions` from `pomerado/core/guardian/openai` may return `reasoningEffort`, `low` or `medium` (type `GuardianReasoningEffort` from `pomerado/core/guardian/model`), and the review's request uses it on the same model as every other review. A review whose host returns none runs at `medium`, as before. Core picks no effort itself. `GuardianUsage`, and so each review's `guardian.usage`, adds the optional `reasoningEffort` the review ran at. The request's effort can change the provider's hidden instructions, so a review at a different effort from the review before it may read the session's history without its cached prefix: compare `cachedTokens` across efforts before relying on it.
- `MintOutcome` adds the optional `stopReason` (type and schema `MintStopReason`, values in `mintStopReasons`), which names why an unpublished build stopped: `final_text_without_tool`, `turn_budget_spent`, `model_quota_exhausted`, `sign_in_failed`, `account_locked`, `question_unanswered`, `owner_declined`, `site_lacks_capability`, `policy` or `host_unavailable`. It also adds the optional `stopExplanation`: the minter's last answer when it stopped without a tool call, screened for credentials and host-private values and kept only when Guardian's question review of a blocked outcome allows it. `MintFailure` adds `turnBudgetSpent`, and `MintModel.run` may return `finalText` beside `stopReason`.
- A blocked build's `summary` carries the minter's explanation only when Guardian allowed its caller to read it.
- Guardian's publication review may return `publicReason`, one short plain sentence about why a tool was not published, apart from the private rationale. The shared output format adds the field, null for every other kind. `PublicationDenial` adds the optional `publicReason`, screened for credentials and host-private values and cut to `publicReasonLimit` (300) characters. A recorded Guardian response keyed on the exact output format or publication policy text needs recording again.
- The owner may decline a login. `CredentialQuestion` adds the optional `allowDecline`, and `CredentialAnswer` the optional `declined` (`LoginDecline`: `no_account` or `public_only`), which holds no login and saves nothing. `MintDependencies.requestLogin` may answer `no_account` or `public_only`, and a sign-in may fail with `MintFailure.loginDeclined`. The minter hears either as a `login_declined` result, never a failed sign-in, and builds the part of the request the site shows signed out; the host signs in no more and raises no further login request in the build. `MintHarnessSnapshot` adds the optional `loginDeclined`. The local host offers the decline on its first login request, and at the terminal an empty username declines.
- `MintDependencies.abandonSignIn` (optional, answering `AbandonSignInResult`: `abandoned`, or `refused` with a reason and notice) offers the minter `abandon_sign_in`, which gives up signing in so the build goes on signed out. It holds the execution permit, Guardian does not review it, and the host decides whether a build may: it refuses a write build, a task that needs the account and a verified sign-in. `MintActions` and `HostToolDescriptions` add the optional `abandonSignIn`.
- `report_blocked` no longer refuses with `sign_in_unresolved` once sign-in is unavailable while a retained receipt held the ending back: it ends the build with the sign-in's own result.
- Once a build abandoned its sign-in, through `abandon_sign_in` or an applied `login` change `signed_out`, it stays signed out: `authenticate` comes back `sign_in_abandoned` without running and a question routed to sign-in asks for no login, until a later applied `login` change `sign_in` or `different_login`. `MintHarnessSnapshot` adds the optional `signInAbandoned`, so a takeover keeps it.
- `MintDependencies.stopExplanationReviewMs` (optional, one minute by default) bounds the review of a minter's last answer; past it the outcome keeps no `stopExplanation`. A restored ending whose login check was unavailable reports `stopReason` `host_unavailable`. A login the owner declined records no sign-in execution, and after an earlier failed sign-in, a declined login request drops the failed sign-in's guidance.
- The auth skill tells the minter to report an account the site locked and what to do after a declined login, the core skill and workspace guide to ask early about a required value the site never shows, and the workspace guide and `report_blocked` description name the new reasons.
- Sign-in pieces the local host runs are exported for other hosts: the recorded rejection marker read (`autofillMarkerVisible`) from `pomerado/core/destinations/autofill-marker`, the signed-in marker's settle wait (`settledMarkerCheck`, `markerSettle`) from `pomerado/core/destinations/marker-settle`, the login prompt and notice texts (`credentialPrompt`, `credentialMessage`, `correctionTriesLeft`) from `pomerado/core/runtime/credential-prompts`, the rules for reusing an answer to a script's question (`scriptQuestionKeys`, `reusedScriptAnswers`, `keptScriptAnswers`, `forgetScriptAnswers` and the `KeptScriptAnswer` schema) from `pomerado/core/mint/script-answer-reuse`, and the login field helpers from `pomerado/core/runtime/login-values`. No prompt or notice text changes. The local host's `check_signed_in_marker` now stops checking a loaded page once its next half-second check would start more than 10 seconds after the first, rather than checking once more at the 10-second mark. Its rejection marker read no longer refuses a screen whose address carries a user name or password, and a recorded popup reported missing when the step recorded none fails the read rather than reading as no marker.
- A publication refused, fixed and submitted again in the same build is reviewed against what changed since its last review instead of from scratch. Guardian keeps each completed publication round, its decision, each file's digest and screened text within a bound, and which files a review read whole, in its session, and the next round's request adds `publication_delta`: the prior decision and findings with their quoted text, each indexed file as unchanged (and read whole), unchanged but never read whole (a search, which shows only slices around each match, doesn't count as a read: its reads still go through `ReviewTurn.readSource`, so a host that wraps it keeps seeing them, inside the new optional `ReviewTurn.uncountedReads`), changed (with a unified diff, or the whole file when that is shorter), added, removed or not compared, and the other request fields that changed. `publicationDeltaPolicy` follows the review's policy, a host's own included, and asks Guardian to check each prior finding against the change, review what changed, judge unread and uncompared files as in a first review, and leave only read, unchanged files alone unless a change makes them relevant. Every file stays readable and the outcomes are the same; a first round is unchanged.
  - `GuardianSessionSnapshot` from `pomerado/core/guardian/session` adds the optional `publicationRound`, so a host that saves and resumes the session keeps the record across a takeover with no change. It is stored loosely and decoded when used, so a round this release cannot read never fails the restore; it is dropped. An older snapshot has none, and its next round is reviewed as a first one.
  - `ReviewSources` from `pomerado/core/guardian/review` adds the optional `publicationDelta`, and `guardian.started` for a later round counts its files by state under `delta`. Every publication review reads every indexed file through the host's reader once, up to 4 MiB each and four at a time, without counting it as Guardian's read; a file longer than that is not compared. `wholeSource` from `pomerado/core/guardian/source` is joined by `completeSource`, which returns undefined rather than a prefix for such a file.
  - A host that sends small publication files inline in its own request can leave out the ones the delta lists as unchanged. A recorded Guardian response keyed on a later round's exact request text needs recording again.
- The minter asks one question round per form page. The forms skill now opens with that rule, so a builder reads it before its first question: before the first `act` step it asks up front for every field it can see or anticipate, and on each later page it first fills every value the request, the input and earlier answers supply, then asks everything still open on that page in one `request_input`. A field that appears only after an answer is still asked in place. The rule moved from the skill's "Multi-step forms" list, and the `forms.step-rules` section marker moved with it, still ahead of `forms.fixture-checks`. The writes skill's rule for an option the input does not settle points to it.
- On a write, the workspace guide prefers keeping the value the page already shows in an optional field that adds no cost over asking the caller to confirm or correct it. The value is listed in `assumptions` and stays an optional input. Add-ons, pre-selected paid options and saved payment are still asked. Guardian's question policy prefers reword, on a write too, for a question that only asks to confirm or correct such a value, or asks about a control with exactly one possible value. A recorded Guardian response keyed on the exact policy text needs recording again.
- The core skill's first bullets say to prefer a role locator's name from an ARIA snapshot over `textContent` or `innerText`, which include hidden labels, and to prefer `waitForOutcome`, with the step as its `action` and every result it can lead to named, over `waitForURL` or `waitForLoadState`, since a dialog keeps the URL and a route change without a new document passes `waitForLoadState` at once. The deeper paragraph that named every answer moved into that bullet, and the line on waiting after a navigation now prefers `waitForOutcome` with a control only the destination page has over waiting for the destination URL alone.
- The core skill's click bullets prefer waiting for the page a click opens, which may be a new tab, over waiting on the old page's URL, and prefer clicking a control's visible label when its input is hidden. A script that waited on the old page after a click opened a new tab timed out, and one that clicked a radio whose input a custom control hides failed.
- The core skill points the minter at the site's other tools when `reference/site-tools.json` exists: it reads the index `reference/site-tools/README.md` first, then the per-tool folders it needs, each with a `README.md` and, unless the index omits it, the tool's full source. It reuses their identifiers, field names and shapes, and copies and adapts their code into its own `src/` files, but never imports, reads or references a file under `reference/` from its code, and checks what it copies against the site as it observes it now.
- The core skill says `waitForOutcome` returns the name of the answer that showed, and prefers branching on that name over waiting again for the same answers or rechecking them with `isVisible`. It also prefers the wait helpers' own settling over a tool's own loops that poll until values hold still, since `waitForRows` and `waitForValues` already return only once what they read is filled in and reads the same on two looks.
- The core skill says that when the site's own search has no match for the caller's value, the tool throws `InvalidInput` with `field` and `available`, the closest entries the site showed, rather than only naming them in the message, so the host can end the run at once with those choices.
- The core skill's input schema rules, beside the rule that a repair fixes a broken declared input, prefer fixing the whole class of a failure over its one instance: when the page requires a control the input has no value for, the tool prefers making every such control a declared caller question with the page's live options over throwing for it.
- The minter's `read_source` reads up to 10 files in one call. `paths` lists them, each with its own `offset` and `limit`, and `path`, `offset` and `limit` are null. Each file reads as a call naming only it would, with the same default and maximum length, and the results come back in order as `{ kind: "untrusted_sources", files }`. A file whose read fails returns its own failure in its place without failing the others. A call that is cancelled or times out stops before its next file, as a single read does. Once the results reach 200,000 UTF-16 code units, the files left come back as `not_read` with reason `call_size_limit`, unread. A call naming one `path`, including one recorded before `paths` existed, reads as before. The `read_source` tool description says so.
  - Each file is its own host read through `MintActions.readSource` and its own `ModelObserver.tool` dispatch, with that file's `readPath` and arguments, under the model's one tool call ID. A host that counts skill reads from `readPath` counts each file whose read returned, and no other. No host interface changes.
- The testing skill and the `live_tests` instructions tell a read signed out to rerun its failing cases together in one batch while a fix is in progress, not one batch each, since each batch waits on its own Guardian review. The testing skill and the `live_tests` tool description no longer say `maxWorkers` sets how many cases run at once: the `LiveTestHost` contract says a host may run a batch's cases on up to its own `maxWorkers` browsers at once, whatever `LiveTestBatch.workers` or the request's `maxWorkers` says. The `maxWorkers` field stays in the `live_tests` request, so older hosts and callers keep working.
- The testing skill prefers trying other records as one batch of live cases over one probe at a time. One Guardian review covers a batch, while each probe waits on its own review, so trying records one probe at a time slowed builds.
- The auth skill, beside the rule on recording an account choice, prefers exercising a chooser step from both starts in the build, right after a sign-in and from a saved session already past the chooser. A tool whose build ran its chooser step only right after sign-in failed on runs that started on a saved session, which skipped the chooser.
- The publication skill's checks before `finish_build` open with one line: before the first `finish_build`, prefer checking the tool against each rule the request states for its inputs, outputs and refusals. A build took several publication rounds whose refusals mostly restated rules its request had already stated, and each round costs minutes.
- The writes skill says a commit that went through, with the new record's id, already proves the write, and that a read-back after the commit compares the caller's text normalized as before it, through `normalizeText` from `pomerado/runtime`, since sites reformat what they save. It compares a chosen option's value only where the view shows that value, and its label otherwise, and prefers finding each value in the record by a stable id, its column header or a `data-` attribute over its cell's position.
- Guardian's "Unapplied supplied input" rule no longer flags a read's tailoring input whose description says the site picks the value when the caller gives none, or may apply another, which the output labels. A recorded Guardian response keyed on the exact policy text needs recording again.
- The core skill says an input that tailors the answer on a read is the exception to keeping required inputs required: it is optional unless the task can't run without it. The writes skill still keeps the inputs a write states required, while the core skill's guidance for tailoring inputs, optional unless the task can't run without them, still applies to any tool that offers one, a cart tool included. It also says `<input>_note` is an optional output field, set only when the site won't apply the caller's value.
- `LiveTestInconclusiveReason` in `pomerado/core/mint/live-tests` adds `site_block`: the site blocked the browser's network egress, such as an edge refusal of the page's own data call or a bot vendor's block page, so the case tested nothing about the tool. `judgeCase` judges it inconclusive and tells the minter it is an egress problem, not a script failure, so it does not change a working script for it. A host that maps every reason, such as to its own text, adds this one.
- A caller's answer to a design question about how an input is used is respected. An input that tailors the answer, such as a location or store, may have a limited use, such as a postal code used only to look up nearby locations without changing the selected one, when the caller chose that use. The minter asks it as a `request_input` choice question with id `input_use_<input>`, `<input>` being the input's name in lowercase snake_case, so a camelCase input such as `postalCode` is `input_use_postal_code`, offering the full use beside the limited ones, and records the chosen use in the input's description, starting "By design:".
  - Guardian's `publicationOutputPolicy` counts such a documented use as the input applied, not an unapplied supplied input, when `trusted_authority.answeredQuestions` holds the caller's answer under that id. A "By design:" description that misses or contradicts the answer, or that no answer backs, is still a finding, and so is an answer to another question. A filter, sort, date or other value that restricts the answer stays strict whatever an answer says. The "Unapplied input" rule points to the exception. A recorded Guardian response keyed on the exact policy text needs recording again.
  - `AnsweredQuestion` gains an optional `id`, the question's id in its request. `answersForReview` sets it, and Guardian's review input passes it in `trusted_authority.answeredQuestions`, so an answer binds to what it decides by id, not by prompt text. A host that builds its own answers may add it.
  - `PublicationScope` gains an optional `publishedInputs`, each `{ name, description? }`: the inputs the tool's published revision declares. A host that repairs a published tool may supply it from its own record of that revision, never from anything the minter wrote, and Guardian then lets a repair keep a "By design:" description that revision declared for the same input word for word, as the caller's earlier decision. Without it a repair needs the caller's answer in its own job, like a first build. The core review passes it in `trusted_publication`; the local host keeps no published revisions and supplies none.
  - The core skill replaces its rule that no answer makes a supplied value lookup-only with that exception, teaches a first build to ask the question when an input's use is genuinely ambiguous, and tells a repair to keep a "By design:" input's use and description word for word, changing the use only after asking the caller again. The workspace guide lists the question among the reasons to ask.
- The testing skill, the workspace guide and the `live_tests` instructions tell a read signed out to prefer rerunning only the failing cases while a fix is in progress, then to run every case once more after its last edit, before the example. A batch of every case waits on its slowest case, so rerunning the cases that already passed after each fix slowed builds without adding evidence. The publication record is unchanged: a case that ran before the last edit is still stale.
- The core skill says `readRows` and `waitForRows` read every returned row of a list in one call, and the search skill asks for the facts each card shows without a click.
- The testing skill tells the minter to stop reworking a click once a case fails at the same control after two fixes, usually a custom widget, and to apply that input through the results URL the site produced or the page's own data request in the HTTP version, reading it back from the site's committed state or the answer. The search skill allows either route when a control is unreliable. The search and testing skills also say that when setting one control reloads the result list, such as a location or store, it goes before the filters and sorts its reload would drop, and that after each reload the tool waits for the row identifiers or results header to change and settle, never for every card's value to hold.
- The http-mcp, testing and workspace guidance treat publishing a read's HTTP version alone as a normal outcome, not a fallback: once the HTTP version passes its tests and the example ran on it, the minter publishes `http` alone, even while the Playwright version is incomplete or fails a case, and stops fixing a Playwright version it will not ship. Inputs are still read back from the answer, and a version that does not ship is neither recorded nor judged. A repair of a read may finish the same way, including a tool that shipped only its Playwright version, while keeping the tool's inputs and outputs.
- `MintFailure` gains the publication reason `input_contract_changed` with `brokenInputs`, each `{ field, change }` (type `BrokenInput`) with `change` one of `removed`, `required` or `changed`. A host that compares a publication's input schema with the published tool's refuses one that changes a declared input by failing its `publish` with it. `finish_build` hands the minter exactly its fixed instruction with `brokenInputs`, neither a review nor an outage, and records the refusal with recovery `new_observation`: the minter restores each input, keeps every new input optional, runs the example again with the edited code and publishes that execution. Core ships no comparison, and the local host refuses none.
- Guardian's publication output policy adds "Unapplied supplied input": code or an output field that lets a run return results when a valid value the caller supplied did not apply, such as a filter, sort or date the page ignored or reset, is a `schema_mismatch` finding with reason `source_correction`. That covers an output flag such as `sort_applied: false`, results for the page's own default, or a "best-effort" or "lookup-only" description. Facts the page shows for the applied value, such as availability at the applied location, stay data. Neither the description nor an answer to a question excuses it. Returning the site's own default when the caller supplied no value, and saying so, stays fine. Inputs that tailor the answer, such as a location, store, delivery or pickup mode, vehicle, or membership or rate type, are the exception in a read: once the code has tried each way the captures show the site offering to set that value, returning the site's results with the value it actually applied, read back from the page and shown beside the caller's value with the site's message, is right, while skipping a way the captures show, hiding that the applied value differs or presenting the results as the caller's is the finding, fixed by trying those ways and labeling the result. So is code in a read that submits caller details in a step the captures show creating an account or a lasting record on the site. A write throws `InputNotApplied` for such an input before its first commit step. For any other input the fix stays `InputNotApplied` or `InvalidInput`. The live-tests policy counts a tailoring input applied, and one the site won't apply returned with the applied value, as the capabilities to test. 0.4.0 canaries named it "Unapplied supplied location" and covered locations only, refusing them. A recorded Guardian response keyed on the exact policy text needs recording again.
- The authoring skills treat inputs that tailor the answer, facts about the visitor such as where they are (a ZIP, address, store, or delivery or pickup), what they have (a vehicle, a device) or who they are (a membership or rate type, a plan, a business account), as inputs the tool offers when the site lets a visitor set one, optional unless the task cannot run without it.
  - Left out, the site's default applies and the tool returns the value the site used. Given, the tool tries each way the site offers, preferring one that needs nothing more from the caller, reads the applied value back and returns it as `applied_<input>`, such as `applied_store`.
  - When the site still won't apply the caller's value, or says it does not serve a location, a read returns what the site did show, with the applied value beside the requested one (`applied_<input>`, null only when the page shows none) and the site's message in `<input>_note`, never presented as the answer for the caller's value. A read no longer throws `InputNotApplied` for such an input; a write still does, before its first commit step. Filters, sort and dates stay strict and still throw `InputNotApplied`.
  - More detail the site needs to apply the input, such as a street address or a vehicle's trim, is its own optional input, described as sent to the site and submitted only when the caller gave it. A name, email or phone is offered only when the site won't apply the input without it. A step that creates an account or a lasting record on the site is a write, so a read stops before it. While building, a live step, the example's or a test case's, that enters a name, email or phone still asks the owner first, as the execution review requires, and the owner's answer keeps the build a read. The forms skill says a quote, contact or inquiry form that sends a name, email or phone creates a lead or other lasting record, so it is a write, while a step that only sets a tailoring input with details the caller gave, a name, email or phone the site requires for it included, stays part of the read unless it creates an account or a lasting record.
  - The search skill's location section lists the ways to try: the store picker, the ZIP box, the delivery or pickup choice, the manual entry beside "use current location", and declining the browser's location permission. A store missing from the picker, and a store and a ZIP that exclude each other, throw `InvalidInput`.
  - The core, search, caller-input, testing, publication, writes, forms and http-mcp skills and the workspace guide say so. A live test of a location the site won't apply expects a labeled result, not an error.
- The caller-input skill now owns validating a tool's input and choosing its error, and the minter reads it before settling any tool's inputs and errors. The input schema holds every rule it can express: types, enums, bounds, formats and required fields. Rules it cannot express, such as an end date on or after its start date, a count within the site's limits, inputs that exclude each other or at least one of a set, are checked before any site action and refused with `InvalidInput`. `InvalidInput` is for a value that is wrong or that the site does not offer, with `available`. `InputNotApplied` is for a valid, offered value the page did not apply. A greyed-out option on a read is unavailable data, not an error, and a write that may have changed the site is never retried.
- The authoring skills settle how a tool treats inputs the page does not take:
  - An option the page lists but greys out, such as a booked date or a sold-out size, is data on a read: the requested value unavailable, with the page's reason and alternatives, and the run succeeds. A write throws `InvalidInput` with `available`. A value the page does not list at all stays `InvalidInput` with `available`. Neither picks another value.
  - `available` for an input that depends on another, such as a check-out after a check-in, is read after the input it depends on applied. Rules the input alone breaks are checked before any site action.
  - A removed or not-found record page is a named outcome that ends in `InvalidInput` with the page's words, never a readiness timeout.
  - A number on a stepped scale, such as a price slider, snaps to the nearest step inside the caller's bound (down for a maximum, up for a minimum), and the tool returns the applied bound. The workspace guide's read-back rule names this and a disabled filter group as the two cases that return results with what applied. The "value the page does not offer" rule covers choice lists only, and a filter group the page disables for a result set is reported, never waited on.
  - Read-back text compares normalized for case and whitespace, locators never use generated CSS class names, and checks that values stopped changing ignore text that changes on its own, such as countdowns.
  - Search results keep related items, recommendations and duplicates out of the matches, and mark a card that stands for a group of variants.
- `report_blocked` takes the reason `host_unavailable` (`BlockedReport`) when the host has ended live execution and what the build still needs cannot run without it, such as the fresh example a source correction needs. It ends the attempt with the host's failure (`hostFailure: "host_unavailable"`), never as blocked, and runs no explanation review; while the host still offers live execution it is refused as `host_available`. `BuildBlocked` and the recorded `blocked` outcome are unchanged. The workspace guidance no longer says a retained receipt may take a source correction once live execution ended: only unchanged source publishes against it. The HTTP skill says to try an HTTP version while building, before the final example, so `finish_build`'s ask is only a backstop.
- One output check for every place that looks at a tool's output: `lintOutput` in `pomerado/core/runtime/output-lint`. It is deterministic and site-independent, and names each finding by field path (array positions folded to `[]`), check and count. It flags script code, style rules, markup and template leftovers, which block publication, and JSON held as text, invisible characters, untrimmed or very long strings, text that may have been read collapsed (a value ending in an expand control's words such as "Read more", the label of an expand control from `controlLabelsFromAriaSnapshot`, a button or on-page link such as "Show more" right after text, or an ending ellipsis on a page that offered one), one field restating its siblings (a whole card's text), repeated entries or records, and list fields that never vary or are always empty, which are flags for the publication review. The blocking checks need strong signals, such as a function or arrow body, a call or assignment on a DOM global, a statement-ending declaration, embedded JSON-LD, a selector block with style declarations, an HTML element's tag or an unreplaced placeholder, so specs, prices, policies and citations that run long with parentheses and semicolons are not flagged. Every pattern's work per character is bounded by a constant, and the leak checks read at most the first 16 KB of a value; a value that is JSON as a whole is never read as script. A field whose schema declares a code or markup `contentMediaType` (`text/javascript`, `text/css`, `text/html` and a few other named code types) keeps its findings, reported as not blocking with that type as their `override`, so the review sees them. The whole-card and repeated-words checks stop at a work budget on very large outputs and mark their findings `partial`.
  - The local host adds `outputChecks` to an execution's observations when its output has findings, with samples, so the minter fixes the read before publishing.
  - `finish_build` refuses a read example whose output still holds a blocking finding, with the new reason `output_checks_blocked` and `MintFailure.outputFindings`, before the contract review. `PublicationRequest.outputOverrides` lets the minter keep any flagged value that is correct as returned, such as code on a tool that returns code or page text that only resembles code, with a reason the publication review checks against the captures.
  - `outputNotes` and `outputNotesPath` in `pomerado/core/mint/output-notes` give hosts the same check at publication: the blocking findings, and `publication/output-notes.json`, every finding with each override and its reason, as host evidence for the publication review. Guardian's publication policy adds `publicationOutputNotesPolicy`, which treats every finding as a lead to verify, never a verdict. Its Lost information rule counts text that ends in or holds an expand control's label, or ends in an ellipsis, as trimmed only when the captures show a fuller copy on the page the tool read, never a snippet the site cuts short itself or an `include` section an example did not ask for.
- `pomerado/runtime` adds `visibleTextCode`, page code that defines `visibleText`, `visibleTexts` and `readRows`. They read only the text a person sees on the rendered page, never a hidden copy, a script, a style or a template, normalize whitespace and remove characters that never show (keeping the zero-width non-joiner and joiner, which spell words and join emoji), read a `display: contents` row through its rendered children, and fail with a `VisibleTextFailure` naming its reason and counts rather than fall back to hidden text. `as: "accessible"` reads what a screen reader reads instead. `readRows` reads a window of rows in one call, and fails as `hidden_only` when rows matched and none is rendered while one still has a box, such as rows fading in from `opacity: 0`; rows with no box at all, such as a no-results page's `hidden` or `display: none` template row, read as `[]`. `normalizeText` applies the same normalization to text outside the page.
- The authoring skills read values with `visibleText` or `readRows`, expand collapsed text before reading it, return each fact once, keep related records out of a list's results, mark a card that stands for a group as a group, and offer costly or bulky parts of a page through one optional `include` input, such as the site's filters, each record's whole text or related records.
- `waitCode` from `pomerado/runtime` declares the page waits `waitForOutcome`, `waitForRows`, `waitForValues` and `waitForChange` and `waitReport()`, over one set of budgets in `timeoutDefaults` (navigation 30 s, action 5 s, `answer` 8 s without progress, `answerCap` 30 s, `settle` 0.5 s, `unchanged` 2 s, `lateFillCap` 15 s). A wait keeps going while the page shows progress (a loading sign, DOM changes in a named `region`, the site's own document or API request in flight, a URL change, or its own reads filling) and fails with a readable reason once it shows none. `outcomeWaitCode` still declares only the names it declared before, `waitForOutcome` and its four `outcomeWait…` helpers, with the rest kept inside, so code that pastes it beside helpers of its own still parses; paste one of the two, never both. A generic loading sign (a busy region, an indeterminate progress bar, a skeleton, shimmer, spinner or loader class) counts only while it is new, and determinate bars and form controls never do, so a page's decoration holds a wait for at most the no-progress window; the site's own sign passed as `loading` counts for as long as it shows. `waitForRows` also waits while a visible sign shows beside its rows, never inside one: one there before the action, in the same number, is the page's own, and any other counts until it and the rows have held for `noProgressMs` with no request the action started in flight, so a sign that never leaves costs one window, never the cap. A request the wait's `action` started counts until it ends, up to `lateFillCap`, and the page then gets `unchangedMs` to render; any other request keeps the page busy for at most 4 s, since long-polls and streams stay open. A request repeated with the same method, URL and body at a steady interval is a poll and is ignored, and requests to one API path with different bodies are not. Without `siteDomain`, the site is the page host's last two labels, or three under a country's shared second level such as `co.uk`. `waitForRows` reads each field from its first visible match and reports a needed field, or a row's key, whose matches are all hidden as `hidden`. `waitForOutcome` adds `noProgressMs`, `loading`, `region` and `siteDomain` and the reason `outcome_unknown`, and its `timeout` defaults to the 30 s cap while the page keeps progressing; its `outcome_timeout` message now also names the progress it saw.
- Guardian's execution policy and the publication finding "Built URL" allow a tool to open a URL built from the site's own pattern, as the authoring skill now describes: a URL the site's controls produced, with only the parts that carry each input filled from the caller's values, through `URLSearchParams` for a query part or `encodeURIComponent` for a path part, every input read back from the page, and the page's controls run once instead when the landing is not an expected answer or a read-back differs. A guessed parameter or route, iterating on URL variants, an opaque filter code the page did not produce in that run, and a built URL without a read-back stay denied. A recorded Guardian response keyed on the exact policy text needs recording again.
- A tool's call that ends with `outcome_unknown`, `values_loading`, `values_timeout` or `change_unknown` now fails as a `BrowserActionTimeout`, as `outcome_timeout` does.
- `probeCallCode` from `pomerado/core/runtime/host-execute` wraps an exploration probe's call so its actions default to the 5 s action budget, and the local host applies it to every call of an `explore` step.
- A read that has not signed in tests itself: the minter designs live test cases from what it saw on the site, runs them in batches and reads every result. Only a read signed out tests beyond its example; a signed-in read and a write prove the tool with one run (see the breaking change on test scope).
  - The new minter tool `live_tests` has two actions. `plan` returns the agent's cases in `test/cases.json` and each case's latest status, result and failure, with the authored source line that threw. `run` runs the named cases, or all of them, as one batch after one Guardian review, each case on a page reset like the example's, and returns every result. A case may also run the next page through the tool's own cursor. The first passing example's receipt reminds the agent to design and run its cases once the schemas are settled.
  - Each case says in `purpose` what it establishes, and the file's optional `notTested` lists what the agent chose not to test, each with `what` and `reason`. The host derives no checklist: the testing skill guides the agent's design, with every input alone and together, smart combinations of controls, different real values unlike the example's that the site lists (another retailer, store or record with another layout), a value the site does not offer, no results, the next page, a location applied and one the site cannot apply, and one rerun of the example's input on a fresh browser. A read is a list read by its shape, an output that is an array or a results list, and `primaryListOf` names that list; a details record with image or variant arrays stays a details read, and an empty array inside it is not an empty result.
  - `MintDependencies.liveTests`, a `LiveTestHost`, runs the batches; `pomerado/core/mint/live-tests` holds the cases file schema, `runLiveTestCase` and the verdicts. The local host offers it and runs a batch one case at a time on its one browser. A host may run a batch on several fresh browsers at once. `LiveTestHost.caseTimeoutMs` names how long one case may run on that host, `defaultLiveTestCaseMs` (60 s, the local host's) when absent, and the harness refuses a batch as `no_time`, running nothing, when less than that is left before the batch's deadline.
  - Guardian reviews a batch once, as `currentExecution.input` `agent_chosen_batch` with every case's id and input listed, and the cursor input of each case that also runs its next page (`batchReviewInput`), judging each case under the agent-chosen input rules. The new mark is also a history entry's `input`.
  - Results never refuse publication by themselves. At `finish_build` the harness gives `publish` its record of the cases on the source being published, as the new optional third argument `hostEvidence.liveTests`, and adds a line to coverage. The local host's publication review reads it as the host-owned file `publication/tests.json`, and Guardian judges the cases there against the tool's claims and the captures: a failing case, or a claimed capability no passing case tests while time remained, is a finding. The coverage line counts the cases as pass, fail and inconclusive. Each case's output gets the same output check as an example's: the agent reads its findings, with their meaning and a screened sample, in the case's `outputChecks`, and the record keeps each finding's path, check, count and whether it blocks. A case's findings never refuse publication; the example's still do at `finish_build`. A case that expects `error` passes only on a declared refusal, `InputNotApplied`, or `LocationNotApplied` from an older runtime; any other throw fails it. A failure stays in the record when the case later passes unchanged on the same source, marked `flaky`, and a retired failure carries `excusedBy` only when a case passes the same input with the same expectation on the published source after the source changed. The record keeps retired cases, ones the agent deleted or changed after they failed, with their last result and input. It says `outOfTime` when a batch was refused for time or a case was stopped by a batch deadline the attempt's own end set, never by a batch's ten-minute cap; then, and for gaps whose cases were only inconclusive, Guardian notes the gaps without refusing, and a repair is never refused for not repeating the example. A record the host could not build says why instead of being left out. A host with its own publication policy can include the new export `publicationLiveTestsPolicy` from `./core/guardian/publication`. `MintHarnessSnapshot` adds the optional `liveTests`, each case's latest result and the replaced failures before them, and `liveTestsOutOfTime`, which old and new workers each restore. A case's digest covers its input, expectation and next page, not its purpose, so rewording a purpose keeps its result.
  - `preflightTestInput` takes an optional `signedIn`. Only false, a read signed out, runs agent-chosen live tests, with no limit. The execute tool's description promises batches only when the host offers `live_tests`.
- A choice the request, the caller or the owner declined is never an input of the tool. The skills say so, and the publication policy makes such an input a source correction. The rules that make every control an input, in the search and publication skills and Guardian's "Unapplied input" finding, make the same exception, and Guardian's question review never allows asking about a declined choice again.
- A local operation's failure names the authored source line that threw, such as `src/tool.mjs:12`, as `LocalOperationFailure.frame`.
- List tools page. `pomerado/runtime` adds `listInputFields`, `listOutputFields`, `startList`, `readList`, `selectRows` and `finishList`, with `ListMechanism`, `ListPosition`, `ListSegment`, `ListReader`, `CursorRefusal` and the limits `listLimitDefault` (20), `listLimitMax` (50), `listCursorTtlMs` (ten minutes), `listCallBounds` and `listDepth`. The new `pomerado/core/runtime/list-cursor` gives hosts `admitListCursor`, `sealListOutput`, `listCursorKeys` and `randomListCursorKeys`; a host signs each run's next cursor and checks a returned one before the run starts, so a script never makes or reads a cursor. The local host does both for `run`, `pomerado run`, served integrations, the minter's own steps and each case of a live test batch, so a `next_page` case's page two runs from the cursor its page one returned, and `PomeradoOptions` adds `listCursors` for its keys and clock.
  - A host that adopts this release's pagination skill must check cursors with `admitListCursor` before a run and sign outputs with `sealListOutput` after it. The checked position reaches the script on a host channel beside its input, never in the input: `executeKernelOperation`'s browser binding and `runLocalOperation` take `list`, `executeOperation` takes `{ list }`, and `withListHost` (`pomerado/core/runtime/list-page`) attaches it. A run without it refuses any cursor that would continue a runtime list, and its `finishList` returns no next cursor (`next_cursor_unavailable: "unsigned_host"`).
  - A cursor is bound to the tool, the inputs other than `limit`, `cursor` and `include`, the caller the host names as `ListCursorScope.subject` (refused as `other_account` for any other) and ten minutes after the call that returned it. Its body is signed, not encrypted: it shows the site's own link, token and scope for the next page. The tool, inputs and caller appear only as digests keyed by the signing key.
  - A cursor in another form, such as a tool's own `page=2`, passes through admission and sealing unchanged, so tools that page their own way keep paging. A runtime draft sent in as a cursor is refused.
  - `readList(list, reader)` reads one call's page from site actions a tool gives it: `open` reaches where the call starts, the first segment or the one the position names, `more` reads more of the open segment without navigating, and `next` moves to the next site page, API response or "Load more" step or scroll. It asks for exactly the rows the window needs, reads on while rows are lacking within `listCallBounds` and the run's time, and writes the next position: the segment that holds the last returned row (its site link and page number, the API token, or the fewest steps that load it) and the offset after that row. A call's `limit` and the site's page size need not match: with `limit` 20 over 30 rows per site page, page two returns site page one's rows 21 to 30 and site page two's rows 1 to 10. Rows inserted above the last returned row move the window down its segment, and the call still returns `limit` rows when its reads allow. Every count `readList` asks a reader for is at most 1,000, or the last segment's rows read plus `limit` when that is more; `open` asks for the position's offset plus `limit`.
  - When the segment a later page opens shows neither the last returned row nor any row the cursor remembers, `readList` looks for them within `listCallBounds`. For `pages`, `next_link` and `api` it reads up to two segments on, since rows inserted above push them on, keeping a read to start over. It also reads the previous segment by its page number, which finds them after removals above of up to about a segment's rows, and resumes there. A reader reaches a page by its number by following Next from the first page, so that read costs one read per page: when the previous segment is the list's first it is read before looking on, since a start over needs it too; an earlier one is read after looking on, only when it fits within the call's reads with one left to start over, never deep in a list. When neither direction shows them, it starts over from the list's first segment in the same call: after the last returned row or a remembered row when that segment shows one, else from the list's first row, repeating rows rather than skipping any. A step back or a start over sets `list_changed`. A start over, or a page continued from a segment's first row with neither the last returned row nor any remembered row in sight, can return rows returned before the 16 the cursor remembers, so the cursor then carries a flag and `list_changed` is true on that page and on every later page from it; callers should de-duplicate by key once `list_changed` is true. `finishList` takes `mayRepeat` for it. A call returns no rows while the list has more only when the run's time or the call's reads stopped it; reads that ran out before the start over hand back the list's first segment. `finishList` takes `resumeAfter`, the key of the row a call that returned no rows resumes after when that is not the previous page's last row, such as a row returned earlier that it read past, so the next cursor's anchor matches its position. `ListReader.open` may get a position with only a `page`: for `api` without a token, fetch the responses up to that page. A cursor remembers the last 16 rows returned across calls, not only the last call's.
  - When the run's time stops a call before it reads past its position, its next cursor holds that same position with `has_more` true; `finishList` takes `bounded` for it. A second such call in a row at that position ends the list with `no_progress`, so a caller paging until `has_more` is false still ends when every run's time runs out before it reads. Otherwise only a call that read and stalled ends with `no_progress`.
  - `list_changed` is true when anything changed at or above the last returned row: it moved from the offset the cursor saw it at (rows inserted above it, which the caller never gets, or returned rows removed), `readList` found it in the previous segment or started over, it is gone, or a row the cursor remembers came back, and on every page after a start over. Rows that change below it are returned without it. A position whose site `token` starts right after that row (offset 0) does not expect it.
  - A site link that carries a session, a credential or a signature is left out of the next position, which then reaches that page by its number: user info, a `;jsessionid=` path parameter, an ASP.NET cookieless `(S(...))` path segment, or a `sid`, `sessid`, `sessionid`, `session_id`, `PHPSESSID`, `CFID`, `CFTOKEN`, `access_token`, `id_token`, `auth_token`, `authenticity_token`, `csrf_token`, `token`, `api_key`, `password`, `sig`, `signature`, `X-Amz-Signature`, `X-Amz-Credential`, `X-Amz-Security-Token` or `X-Goog-Signature` parameter.
  - Every position a draft can hold fits in a cursor of at most 2,048 characters: a draft keeps the last 16 row-key digests and at most 1,360 bytes of JSON. When a list has more but no cursor, `next_cursor_unavailable` says why: `depth_cap`, `no_progress` (a later page that returned no rows and stayed at the position it started from, such as a list that still stalls, so a caller paging until `has_more` is false still ends), `position_too_long`, `unsigned_host`, `off_site`, `not_a_draft` or `inputs_not_json`.
  - `InputRefusalDetail` and `errors.InvalidInput`'s detail add `kind`, a short token such as `expired`, which a run's `input_rejected` outcome carries as `details.kind`, and `RunEvidence` adds `refusal_kind`.
  - The pagination skill is rewritten around this contract and its mechanisms: numbered pages and Next links by the site's own link, load more and infinite scroll by a capped replay, the page's own list API, offsets within a page, changed lists and when to stop. The search, core, testing and publication skills point to it, and `references/pagination.ts` is a paged search tool and a "Show more" list on the same contract (`readRooms`), both reading through `readList`; `readRooms` waits for each step's rows with `waitForRows` and keeps a list that stops growing while its control is still offered open, with `has_more` true and a position that continues.
- Guardian treats a signed-out session's own state as part of a read. Choosing a store or location, a delivery or pickup mode, a filter, sort, option, currency or language, or dismissing a dialog is never a write there, even through a Save button, and choosing among the page's own options for it is not an invented value. Saving a guest address signed out is part of the read too when it only sets the delivery or store location. A signed-out write includes a step that submits or sends something to a person or an organization, such as a contact form, an application, a message or review, a sign-up or newsletter subscription, or an order, booking or payment. Adding to a cart, a hold on inventory, a seat or a time slot, an upload and a draft stay writes. A signed-out quote or price form that only fetches is a read, but any signed-out step that enters a name, email, phone number or similar personal detail, an address dialog that also takes them included, is a write that needs the owner's confirmation, so Guardian escalates it without one. When Guardian can't establish that a session is signed out, it applies the signed-in rules. Signed-in sessions keep the rules they had. The authoring skills say the same.
- A script that refuses a caller's value can name the input and list the choices the page offers for it: `new errors.InvalidInput(message, { field, available })`. The run's `input_rejected` outcome carries them as `details.field` and `details.available`, and the local host's failure text lists them. A host that repairs may close such a refusal without a repair, since the caller has the page's choices, and never asks the caller for a replacement. Only a refusal without choices, of a free-form value, may still be checked and confirmed with the caller. The detail is optional, and a refusal without it is unchanged. `RunEvidence` gains `refusal_field` and `refusal_available`, and `pomerado/core/runtime/operation-failure` exports `boundedRefusalDetail`, which keeps at most 100 non-empty choices of at most 200 characters each.
  - `ExecutionEvidence` gains the trusted host marker `refusal`, `{ field?, available }`. In maintenance of a read, an example whose script refused the caller's value with the page's choices is a publication receipt: maintenance cannot change the caller's input, so that refusal shows the repaired tool behaves correctly. A first build, a write repair, or a refusal without choices still needs a completed example.
- `package.json` declares the host protocol, `"pomerado": { "hostProtocol": 1 }`. It goes up by one whenever a release removes a `./core/*` export hosts use or changes one incompatibly. A package without it is protocol 1. `pnpm test` first runs `tools/check-host-protocol.ts`, which fails when a `./core/*` export of the `canary` or `latest` version on npm is gone without a higher protocol.
- `getRuntimeSources` and `runtimeSourceEntry` from `pomerado/assets` give the modules `pomerado/runtime` loads, computed from its imports, for a host's Guardian source reads and minter workspace. The build writes the same set as data to `dist/runtime-sources.json`, exported as `pomerado/runtime-sources.json`, for a host that reads the package without running it.
- `pomerado/runtime` holds the HTTP version API and only ever adds exports. It adds `SiteHttp` (its service key stays `pomerado/SiteHttp`), `SiteHttpRequest`, `HttpFailure`, `defineHttpOperation`, `readText`, `readJson`, `requestPastChallenge`, `isBotChallenge`, `parseSavedHttp`, `SavedHttpFixtures`, `SavedCaptureEvidence` and `OfflineFixtureUnavailable`, with their types. Authored tools may import it by that package path; the local host resolves it to the modules it runs.
  - `makeSiteHttp` from the new `pomerado/core/runtime/site-http-host` builds `SiteHttp` over a host's `HttpTransport`. Its optional `isChallenge` is the host's test for a bot-protection challenge page, which marks a result `challenge: true`. `isBotChallenge` reads that mark, so without a test no answer is a challenge. The contract modules are `pomerado/core/runtime/site-http`, `pomerado/core/runtime/http-operation` and `pomerado/core/runtime/saved-http`.
  - `runLocalOperation` takes an optional `http` transport and runs an HTTP version over it. Without one, an HTTP version fails before it sends anything.
- `pomerado/runtime` adds HTML reading for HTTP versions, which import no other package. `parseHtml(text)` parses an answer into an inert tree, where nothing runs and nothing is fetched, with `select(css)`, `selectOne(css)` and `title()`, and each node's `text()` (entities decoded, whitespace collapsed), `attr(name)` (only attributes the element has), `html()` and its own `select` and `selectOne`. `embeddedJson(text, selector)` returns, as an `Either`, the JSON a page embeds in a `<script id>`, every `application/ld+json` or `application/json` script, an attribute such as `data-state`, or the object or array a script assigns to a global (`{ assignment: "__STATE__" }` reads `window.__STATE__ = {...}`, `self.__STATE__ = ...` or `JSON.parse("...")` there, with the string's escapes decoded, in classic and module scripts, the last assignment that parses winning), through comment and CDATA wrappers and a trailing `;`; its `EmbeddedJsonFailure` says whether the block is missing or not JSON and names the selector and the page's title. `readEmbeddedJson(http, request, selector, schema)` reads the page with `readText`, decodes the block with the schema, and when a safe read's live answer lacks the block reads once more over the page's fetch where the host can carry it, never from an offline replay, keeping the block's own failure if that read fails; it fails as `parsing`, naming the selector, the page's title, the URL, status and transport. The package now depends on `htmlparser2`, `css-select`, `domhandler` and `domutils`.
- The local host stages and lets Guardian and the minter read the modules `getRuntimeSources` lists, in place of its own list, which missed `runtime/files.js`. Its Guardian reads a bare `pomerado/runtime` as `browser/index.js`, and Guardian's execution policy names `pomerado/runtime` as trusted SDK beside `runtime/index.js`.
- The package ships the `http-mcp` authoring skill and its references `http-version.ts` and `kernel-page-fetch.ts` for a host that builds HTTP versions. The local host doesn't load it. Its section `http-mcp.challenges` holds the bot-challenge guidance, which a host that recognizes challenge pages supplies.
- The minter and Guardian share one navigation rule. URLs built from caller values are brittle, so the minter prefers the page's own controls. A URL the caller supplied, on the tool's site, may be opened unchanged, such as the build's start page or a product or listing page URL input. A stable identifier route the site itself uses may be opened from the caller's identifier when that is clearly better. Either way the page's identity is read back. Building or iterating on search, filter or sort parameters in place of the page's controls stays refused. This replaces the rule that refused any URL holding a caller value.
- `report_blocked` with reason `policy` needs a refusal on record in the attempt: a Guardian deny or escalation of an execution, a refusal of a publication that no correction gets past, or the owner's no to a `confirm` question. A publication refusal counts only when Guardian denies or escalates it with reason `privacy` or `authority`, or names a finding in the categories `private_literal`, `credential`, `customer_data`, `exfiltration`, `unsafe_logging` or `safety_default`; the outcome alone never decides it. A denial or escalation that names a correction, such as reason `source_correction`, `unsupported_claim`, `evidence` or `input_feedback`, or an `example_value` finding, is review feedback: the minter fixes it, or gathers the missing evidence the rationale names, and calls `finish_build` again, and the build's other limits stop a finding it cannot fix. `publicationRefusalUnfixable`, `unfixablePublicationReasons` and `unfixableFindingCategories` from `pomerado/core/guardian/review-contracts` hold the rule; `publicationRefusalUnfixable` reads only the review's `reason` and `findings`. Without a refusal the host refuses the block as `policy_not_refused` and the build goes on. A host whose own guidance names a `policy` ending, such as a repair's verdict on the caller's input, allows it with the new `MintDependencies.policyBlockAllowed`, which gets the screened explanation. `MintHarnessSnapshot` gains an optional `guardianRefused`, so a takeover keeps the record.
- A publication denial with reason `host_owned`, whose every finding is in a file the host wrote, ends the attempt at once as the host's own failure, `hostFailure: "publication_unavailable"`, with the denial in `publicationDenial`. It used to go back to the minter, which no source edit could help: the build ran on until its final-answer limit and ended incomplete with no host failure, or the minter's `policy` block was refused. This ending recurs on every build until the host fixes its own file, so a host should treat an outcome that carries `publicationDenial.reason: "host_owned"` as final: it should not requeue the build or offer a retry, as it may for other host failures.
- A `finish_build` that changed nothing since Guardian denied a publication is refused before review, as `unchanged_since_denial` with recovery `correct_source`, instead of being reviewed and denied again; the denial stays the build's `publicationDenial`. The harness compares the request, the digests of the entrypoint's and `src/tool-http.mjs`'s import closures and of each file the denial names, and the attempt's executions, live test results, task revision, answers and retained captures. It keeps the comparison in memory only, so a takeover drops it and reviews the next submission.
- The workspace guide and the `report_blocked` description name every finding category a `policy` block may stand on, and the guide tells a repair to keep every declared input and output rather than narrow the tool. The continuation prompt says a publication denial that names a correction or missing evidence is feedback to fix.
- The minter's guidance asks for broader tools and fuller tests. A read signed out runs as many live tests with an input the minter chose as it needs (`preflightTestInput` in `pomerado/core/mint/step-checks`), and the testing skill asks it to test every control it exposes.
  - The core skill adds "Configure, then read": discover a page's choice groups, set them from the input, confirm, then read the values that depend on them. A value the page does not offer throws `errors.InvalidInput(message, { field, available })` listing the page's choices. The runtime change that adds that second argument, and the host behavior that ends such a run at once with the choices, are in this release (see the `InvalidInput` entry above).
  - Tools expose every control that narrows, orders or configures their results, a location or store included on search, details and cart tools when the site lets a visitor set one. Setting a location, filter, sort or option in the run's own browser is part of a read; Guardian's execution policy says so in the same words, and saving to a signed-in account stays a write.
  - Output schemas lean toward more information: the facts a caller could reasonably use, with full displayed values and split values, such as a maker line above a name, in their own fields. A field the code never reads is a defect, and narrowing an output claim is no longer the default remedy.
  - A value the request needs is never loosened: it is required and non-null. Only a record whose own page shows no such value may return null, together with a field saying why. A value the page shows that the code failed to read throws instead of returning null.
  - Reads wait for the values they read, not their containers, clear overlays and expand sections before clicking, never swallow a failed wait, and check after extracting that the page did not re-render.
  - A repair fixes any declared input it finds broken, and never asks the caller for a replacement value.
- The core authoring skill asks for plain `locator.click()` calls, with at most a `timeout`. A hosted browser may make such a click a real pointer click, after the same checks Playwright makes. Options such as `force` and `position` keep a synthetic click.
- Operations take and return files. `FileInput` and `FileOutput` from `pomerado/runtime` type a file field, marked `format: "file"` in the published JSON Schema. A script's `files.place(reference, { field })` puts a caller's file into a file input on the tool's site, where `field` is data, `{ label, exact? }` or `{ selector }`, never page code, and `files.collect(trigger)` returns a download as `{ "$file": { id, name, media_type, size, sha256, download_url?, expires_at? } }`. Bytes never pass through page code, its results or JSON bodies.
  - The local host takes a `file:` URL in the input and returns a download's `file:` URL, which expires after 30 minutes. `PomeradoOptions.files` sets where downloads are kept and the caps, 25 MiB per file and 10 files or 50 MiB per run by default. Without a directory, downloads are kept in the process's temporary directory, removed when it exits.
  - A placed file is checked by its first bytes against its declared type and the input's `accept`. The host checks the element the field names and sets that same element in one page call, only when it is a file input in a frame on the tool's site. A refusal of the caller's file (`too_large`, `run_limit`, `type_mismatch`, `executable`, `not_accepted`) fails the run as invalid input naming the reason; a refusal before the page call reports nothing sent. A download's type comes from its first bytes, else the server's `Content-Type`, never its name. Programs are refused either way.
  - The minter sees a caller's file as a `{{file.fN}}` handle with its name, type and size, listed in the new `MintRequest.files`. A live step or publication whose source holds a handle is refused, publication with the new reason `file_handle`. One whose source reads a file's contents is refused too, and in a build with files also one that sets a file input itself, takes a download itself, reads an input's files, or routes the page's requests, publication with the new reason `file_readback`; `fileReadback` and `fileReadbackRefusal` are in the new `pomerado/core/mint/file-readback`. That check is static, and Guardian's execution policy gains a `{{file.<id>}}` rule that denies the same reads.
  - Setting a file input with `setInputFiles` from bytes in a tool's own input, such as base64, is deprecated in favor of `FileInput` and `files.place`. A build with no file handle and no `FileInput` may still do it, so repairs of tools built that way keep running.
  - `file_download` in `IntakeReasonCode` is deprecated, since a tool can return a downloaded file. It still decodes; a later release removes it once hosts stop emitting it.
  - Other hosts implement `FileHostHook` and call `makeRunFiles` from the new `pomerado/core/runtime/file-transfer`, bind the result as the runner's `files`, and pass the minter handles from `issueFileHandles` in the new `pomerado/core/mint/file-handles`. `pomerado/core/runtime/files` and `pomerado/core/runtime/file-types` hold the contracts and the type checks.
- A publication finding whose byte range runs past its file or is empty is fitted to the file instead of discarding the denial.
- The publication policy adds `publicationOutputPolicy`, `publicationCartPolicy` and `publicationFindingFeedback`, exported from `pomerado/core/guardian/publication` for hosts with their own policy. `publicationOutputPolicy` also refuses Playwright source that opens a page URL holding a caller input value.
- The execution policy settles the sign-in method in the order the caller's choice, a password, then a code, until the host picks it, denies opening account areas a task does not concern after sign-in, counts related results and listing pages as discovery, lets a step decline optional setup such as adding a passkey, denies any passkey or security-key step, refuses a page URL holding caller input in an example, test or act step, and no longer treats a read's filters as defaults. The question policy leaves the sign-in method to the host when it holds a login, still allows asking where a code is sent when nothing names it, and allows asking for the location a search's results depend on, which the owner may decline.
- `SpentSignIn` adds `sign_in_retry_spent`: a host refuses another sign-in once the attempt's one retry of a sign-in that submitted the login but never verified, and was not rejected, is spent. The agent and the build's owner read why. `relogin_spent` now reads as the attempt's one extra sign-in, which a host may also run on a recovery's new profile.
- The local minter's `AGENTS.md` starts with the features the shared prompts describe that another host supplies and the local host lacks, which the minter ignores. The local Guardian's execution policy ends with the same list, as protections it doesn't count on. `typescript/src/hosted-features.ts` holds the list, one line per entry, and a change that brings a feature to the local host deletes its entry. `GuardianExecutionEnvironment` gains an optional `absentProtections`, the policy's last line. A host that leaves it out gets the policy unchanged.
- Guardian's core publication policy, which the local host uses, no longer says the published files passed a deterministic credential precheck. It says the local precheck covered only the build's own caller-supplied values and secret handles, and asks Guardian to inspect every published file for hard-coded API keys, tokens and passwords. It also says this host has no data-vendor exception.
- The local minter reads the shared text where its own sections were empty or different, and the testing skill. That covers the write session's steps, declared questions, sign-in screen fields, the login URL rules, the workspace map, the tool list and how Guardian sees the build. Where that text describes a feature the local host lacks, the list on top of `AGENTS.md` tells the minter to ignore it.
- A script's `ensureSignedIn` now signs in again on a local run or build when the page reads signed out. Before, the local host always answered that it didn't sign in again.
  - The host checks the recorded signed-in marker on the current page without moving it. A marker that names a path reads signed out only on that path.
  - On a page that reads signed out, it first checks without typing anything. It then replays the recorded sign-in on the same browser and page, with the login it already holds, and asks only for what the screens need.
  - A run makes at most 3 such sign-ins. A build makes at most 4 per attempt, across a change of site too, and 1 per check. Past that, a build ends with the session not kept, and a run fails with `RunOutcomeFailure`.
  - A run whose page reads signed out and that can't sign in again, because its sign-ins are spent or the sign-in failed, reports `website_sign_in_unavailable` with the retry class `same_key`. That holds for a read, and for a write that sent nothing or entered none of its declared commit steps. Such a write's status is `not_applied`, or `not_attempted` when it sent nothing. A run whose journal shows a commit step entered, or commit marks it can't read, never reports it, even when its request says it reads. Any other write keeps the outcome its journal shows, `outcome_unknown` while it may have applied, so a retry can't repeat it. A run given no effect, as `pomerado run` is, follows the write's rule. A served run's failed job carries the same code and retry.
  - A username or password the site rejected during one of these sign-ins is never sent again. The next sign-in asks for a correction before it types, asks once more when the correction repeats the rejected value, and refuses after that. A rejected code, date of birth, ZIP or recovery code is asked for fresh, with the login kept.
  - The operation's deadline pauses meanwhile. No sign-in step starts after the sign-in's bound, and a question it asks waits no longer than that bound.
- A signed-in build checks its signed-in marker after each reset that restores its saved session. When the reset's load signed the site out, the build signs in again before the step runs, saves that session and resets once more.
  - A marker the site's root doesn't show can cost more at each such reset. A marker that names a path costs nothing there. One with a page to open costs a load of that page and one more reset. A marker with neither, on a site whose sign-in page shows its form to a signed-in browser, signs the build in twice at the first reset and once at each later one, and those steps start on the page the sign-in left. The fourth such reset then fails with the session not kept. Choose a marker the site shows on every signed-in page.
  - A site whose load signs out a fresh sign-in starts each later step on the page its sign-in left.
- The session a signed-in build saves now holds the tab's session storage too, when the whole save fits in the 1 MiB a browser call returns. Otherwise the build saves the stored state alone, as before. A reset that restores the session puts back what it saved.
- `pomerado/core/runtime/session-sign-in` holds the re-sign-in rules hosts share: the allowances, how a marker check reads the session, the bounds of a sign-in a script waits for, and the start check after a reset. `SessionSignInHook` is the host side of a script's `ensureSignedIn`.
- `pomerado/testing/session-sign-in-contract` holds cases that any host's re-sign-in can run against the controlled shop. The shop fixture's home now shows an account link to a signed-in session. It adds an `/orders` page, a `signOutOn` path whose next signed-in load signs the session out, and a count of sign-in page loads. A wrong code now shows the code form again under its error, and `codePosts` counts the codes posted.
- New exports let another host share these modules instead of keeping a copy.
  - `pomerado/core/guardian/publication` holds the publication decision decoder.
  - `pomerado/core/runtime/kernel-operation-run` holds `executeKernelOperation`, which runs a script under the execution context's deadline, capture, events and journal. A host with its own implementation of an operation passes it as the optional `first` runner. The local host never does.
  - `pomerado/core/destinations/autofill-recipe` holds the `auth-fill.json` schemas, `recipeStep` and `autofillRecipe`.
  - `pomerado/core/mint/login-url` holds `oneTimeLoginUrlParameters` and `refuseCredentialParts`.
  - `canonicalSchema` and `withReferences` join `pomerado/core/registry/schema-references`, and `described` and `siteInput` join `pomerado/core/mcp/schema`.
- A version 1 or 2 recipe may name `questionSelector` on any secret field, as other hosts write it. A run reads it only on a security answer.
- Publication asks once about a login URL that is one authorization request, such as an identity provider's authorize URL or one carrying `state`, `nonce` or `SAMLRequest`. The first `finish_build` fails `login_url_one_time` with the URL's one-time parameters. Finishing again with the same URL publishes it.
- Publication refuses a name, description, `siteName` or `siteSummary` that holds a value the build was given, with `metadata_contains_credential`.
- A run of a built integration counts as possibly sent from its start, as the shared runner marks it, so one that fails before its first browser call reports `possible` where it reported `not_sent`. A mint step still counts as possibly sent from its first browser call, and a run with no browser still reports `not_sent`. The shared runner also races the execution deadline, but the local host's own deadline starts first and still ends a local run as before.
- A built integration's MCP server serves an input schema that recurses, with its references under `$defs` at the call schema's root. It used to fail to start with "Invalid operation schema.". The input is titled `<tool> input` and its description adds a summary of its top-level fields.
- Recoverable failures no longer end a build:
  - When Guardian asks for a reword of a `report_blocked` explanation, the minter gets the rationale and may revise or withdraw it. An unavailable review of the explanation is retried under the review outage budget. Only an allowed explanation, or a review that stays unavailable past that budget, ends the build blocked. `MintHarnessSnapshot` gains optional `blockedReviewUnavailable`, so a takeover during such an outage can still resubmit the explanation.
  - A diagnostic copy the host could not keep, such as an execution's diagnostics or a readable model transcript, is a recorded gap, however many there are. The raw record of each model call stays fail closed: a host's `retainRuntimeRecord` failure still stops the attempt before the next model call, with `hostFailure: "diagnostic_retention"`. A host without `retainRuntimeRecord` has no required trace. `MintHarnessSnapshot.diagnosticRetentionRetries` is deprecated and optional: the harness always writes 0, only so older workers can restore newer checkpoints, and ignores it on read.
  - A review whose evidence the host could not keep is an ordinary review outage under the review outage budget, with no `retriesRemaining`.
  - `CaptureUnavailable` from an execution returns a capture gap with a possible effect, and from publication a `not_published` with `retryable: true` until the review outage budget runs out. The harness no longer sets `hostFailure: "capture_unavailable"`; the value stays in `MintOutcome` for older hosts.
  - A publication screening or source read that names no file to fix (`evidence_screening`, `source_screening` or `schema_screening` without `publicationBlock`, or `source_read`) is a retryable publication outage. `path_screening` stays a refusal the minter fixes.
- `MintDependencies.publicationDecisions` is a new optional `PublicationDecisionLog` hook. The harness records each `finish_build` decision as a `PublicationDecision`, with its code, reason, execution, time, failed checks and `PublicationRecovery` path, and the tool result carries its `decisionId`. `reviewQuestion` receives the latest refusals as `publicationDecisions`, and Guardian reads them as `question_review.publicationDecisions` in a question or blocked-explanation review. A task update review gets them too, as `PendingTaskUpdate.publicationDecisions` and `update_review.publicationDecisions`. The local host keeps them in memory for the request.
- The `write_not_submitted` refusal says the requested write was not demonstrated, and tells the minter to continue the remaining authorized work or ask about revising inputs the site cannot take.
- `pomerado/core/runtime/run-outcome` holds the run outcome classifier other hosts share. It exports `classifyRun`, `runError`, `writeStatusOf`, `possibleCommit`, the commit evidence and confirmation checks, `runOutcomeCodes`, `runOutcomeRetry` and the `FailureRenderer` hook.
- `pomerado/core/runtime/failure-renderer-contract` exports `failureRendererIssues`. It checks that a host's renderer words every code with its own text and retry class, and that every possible commit, and every write that may have applied, carries the host's read-back advice.
- A write build refuses a step that repeats an earlier write's entrypoint or the same source under another name until the outcome review, caught up and with no readback outstanding, finds the write did not happen. Guardian's execution review sees earlier writes and their findings in `trusted_execution_context.writes` (hosts pass them through `OutcomeReviewHost.bindWrites` and `MintReviewHost.writes`) and denies committing the same change again. The harness checkpoint keeps tracked writes in `MintHarnessSnapshot.outcomeWrites`.
- A separate outcome reviewer judges each write after it runs, from the minter's whole history and the host's records, and records `done`, `not_done` or `unknown`. `MintOutcome.writes` reports every write with its newest assessment. See `MintDependencies.outcomeReview` and `pomerado/core/mint/outcome-review-contracts`.
- `MintTurn.history` gives the minter a history archive and takes a reader of its run state, so the outcome reviewer reads the minter's whole history, the items before a compaction included, after a takeover too. `OutcomeReviewHost.historyArchive` is the host's durable archive, and `MintAgentSnapshot.historyOffset` records where the run state starts in the whole history; a recovery factory stores the counters' `historyOffset` in it.
- A served write tool takes an optional `idempotency_key`. A call that repeats the key and input rejoins the first job and acts on nothing, in parallel, from a second server on the same folder, and after a restart. The same key with other input is refused with a retry-conflict message, and nothing runs. A call without a key is still a new website action.
  - `pomerado-mcp serve` keeps each keyed job's record in the integration folder's `.jobs` for a day, with the key, a digest of the input, the job ID, its status, and a failed run's outcome and commit marks, never the input or output. `get_job` finds a keyed job after a restart with its status and a failed run's outcome but not its output, and a keyed job a stopped server left running reads as failed and is never run again.
  - `.jobs` is reserved, so an artifact may not use the name. `IntegrationMcpOptions` gains `directory`, the folder those records live in. Only a write tool keeps records there, and `.jobs` is for servers on one machine.
- `pomerado/core/runtime/job-store` exports `submitJob`, the retry-key rule every host shares, with its `JobStore` hook and `RetryConflict`. `pomerado/core/runtime/fingerprint` exports the request `fingerprint`. `pomerado/testing/job-store-contract` exports `describeJobStoreContract`, which runs the shared contract on a host's own store.
- The authoring text and the write examples call `verified()` with no argument and declare `write: { confirmation: "readback" }`, whether the write read the site's confirmation or the saved state. The runtime still accepts `{ confirmation: "message" }` from operations published before.
- The minter reaches every page of a browser version and its probes through the site's own search, forms and links, never through a URL that holds the caller's input. The detail-read example `navigation.ts` types the identifier into the site's search, follows the one matching result link and checks the final path against that link's `href`. Only the site's own word that no record matches fails as `InvalidInput`. A search still loading, or one that failed, does not.
- When a supplied value is incompatible with what the site offers, such as an unavailable option, date or quantity, the minter asks the owner with `request_input` whether to revise it or stop. The question names the value and offers what the site has, and the minter never substitutes another value on its own. Work the request already covers proceeds without a question. Before calling a value unavailable, the minter checks where the site would show it for the requested scope; settled evidence for the requested option is enough.
- Guardian's question review allows the minter's question to replace an unavailable supplied value or stop when settled evidence shows the value unavailable, and no longer asks to reword it as redundant or as asking for more authority. A published tool still throws `InvalidInput` for a value the site refuses: a question review's input marks a question the operation's script asks with `question_review.scriptAsk`, and Guardian rewords such a question that asks to replace the value or stop. `questionForReview` takes the new `scriptAsk` host fact.
- Guardian's question review allows a blocked report that starts "Caller input error:" when it names the input value at fault and why the site cannot fulfil it.
- Guardian's question review leaves the sign-in method to the host only when the host holds a login for the site, as `credentialsAvailable` reports. Without one, it always allows a question asking which sign-in method to use, such as phone or email, when its choices match the page, and encourages one when the method is ambiguous. It still never allows one offering a passkey.
- Guardian's question review keeps a repair's caller-input question to whether the caller's value is invalid or real, and no longer rewords it to offer a replacement value, since a repair can't change the run's input. The rule for the minter's question to replace an unavailable supplied value or stop leaves that question out.
- Guardian's execution policy treats the SDK a source imports from `runtime/index.js`, such as `defineOperation`, `CalendarDate` and `formControlsCode`, as trusted host code. Guardian judges what the source does with it, and never escalates or denies only because it cannot read an SDK file through `read_source`.
- The core skill's input schema rules tell the minter never to derive a format from one sample, such as a zero-padded date key, and to read it off the page for the value it needs.
- The publication skill's checks before `finish_build` add **Typed output**, right after **Schemas**. It prefers parsing what the page shows into typed fields, one per fact a caller would filter, sort or compare on, with a worked example, over one text blob or summary.
- The core skill's output rules prefer parsing what the page shows into typed fields, as the publication skill's **Typed output** check does, so the minter reads them before it writes the schema and the parser. They also prefer keeping every result row the page shows, and make the facts every row has required output fields, typed as `Schema.Int` or `Schema.NonEmptyString`. A row whose fact the code could not read then fails as `InvalidOutput`, which a host that repairs sends to repair, rather than being dropped from a list that returns as success.
- The core skill's input schema rules prefer throwing a plain error for a listed option the code does not read results for yet, over returning results for another option. The run then fails as `OperationFailure`, which a host that repairs sends to repair.
- The core and writes skills no longer tell the minter that nothing repairs a tool whose run fails as `InvalidInput`. A host that repairs checks the value and asks the caller before the run ends that way.
- The core skill's input schema rules tell the minter to look a value up in the site's own search the way a person would, matching names loosely and counting the matches at the best rank. None throws `InvalidInput` at once naming the closest entries, one is used, and several ask the caller with a declared choice question, which the caller-input skill now lists. `formControlsCode`'s `chooseOption` also ignores apostrophe style, so `’`, `‘` and `ʼ` match `'`.
- The core skill's input schema rules prefer keying only on what the caller asked for. A detail that changes from one listing to the next, such as a seating label or a room name, shouldn't decide whether a tool books or refuses unless the caller chose it.
- The writes skill says that on a host that repairs, a failed write run whose marks show no commit step entered reports that it changed nothing, and that its repair fixes the code and runs the write once, without reading the site back.
- The writes skill tells the minter to mark only the step whose click saves or submits. Opening or filling an unsaved form is not a commit step, and the `commit_marks_undeclared` refusal says so too.
- The writes skill tells the minter that the first read-back that matches confirms a write, so it stops there instead of reading more pages. A match shows the written record after the write, found by its number, its own reference or the exact values entered, in one confirmation, list or detail view and never by position, with every field the caller asked for that the view shows in agreement. It reads another page only for a field that view did not show and the output promises, and other rows only where the before-and-after check or another skill compares them.
  - State from before the write never matches: a match needs the number or reference the write produced, or a value it changed, and a list that has not reloaded neither confirms the write nor shows that it did not happen.
  - Entered values find a record but never prove it new. A create matched only by them reads the list before the write too, and only a row that wasn't there before counts. Two rows that match afterwards, with no noted id to show which one is new, don't confirm it by values alone.
- A failed `act` step Guardian labelled a write that may have committed it carries `writeSession` with `verifyFirst: true` and a notice to read the site back before any further write. The local host counts a step as possibly sent when it made a browser call, entered a commit mark or lost its result.
- `finish_build` on a write first checks that the session may have sent its write, and a session that did not gets `write_not_submitted` before Guardian reviews the composed contract. It used to get a contract refusal first.
- A step that lost its result counts the commit marks it entered only once a later step confirms the write.
- `pomerado/core/mint/write-session` exports the write session checks. A host marks a step `possiblySent` when its own record can't rule out a send; the local host sets it from the effect journal. `LocalOperationFailure` gains `reported`, which is false when the host lost the child's result.
- A write's build keeps the confirm popups the owner accepted during its act steps and publishes them with the tool as `acceptedConfirms`, in `pomerado.json`. Each is a SHA-256 digest of the popup's normalized message, page origin and step, never the page's text. Only a confirm on an https page, raised under a step name, whose message holds no secret the caller supplied, is kept, up to 32.
- A run accepts a write's recorded confirm without asking when the same message shows on the same page origin at the same step, once per record. Every other popup still asks the caller. A read tool accepts nothing from the record.
- `finish_build` on a write refuses a composed script whose files never name a step the owner accepted a confirm popup at, with `confirm_action_unmatched` and the steps in `confirmActionIds`. A run could never match that confirm. `checkWriteSession` takes those steps and the entrypoint as an optional `confirms`.
- A run dismisses a popup whose question's window ends unanswered, and goes on. It used to fail the step. A cancel at the terminal, or a question that can't be asked or answered, still fails the step.
- The new `pomerado/core/browser/dialogs/expected` export holds the confirm digest, matcher, recording, the `confirm_action_unmatched` check and the run's popup decision. The new `pomerado/core/runtime/incidents` export holds `IncidentStore`, the hook a host uses to record the popups it settled, and the local `noIncidents`. The new `pomerado/testing/confirm-popups-contract` export holds a fixture page and a check that any host's popup handling can run. `pomerado/core/browser/dialogs/contracts` adds `DialogFacts`.
- `mint_update` gains an `output` change, `{ setting: "output", field, change, text }`, which loosens one output field of a published tool's contract: optional, nullable, removed or widened. Only maintenance accepts it, together with `requirement` and `purpose` changes. Maintenance refuses input, effect, site and login changes, and a recommended new build, before review. The new optional `taskUpdateConfirmer` hook on `MintDependencies` says whether the person answering a repair's questions owns the tool. Without it, or when it answers `none`, a maintenance update is refused as `owner_unavailable`, so the local host still refuses every maintenance update. Guardian reviews an owner's update with the host fact `maintenance: { confirmer: "owner" }`.
- `MintFailure` gains the publication reason `output_obligation_weakened` with `weakenedOutputs`, each `{ field, change }` with `change` one of `removed`, `optional`, `nullable` or `widened`. `finish_build` hands both to the minter, not as a review or an outage. After an extraction fix a read repair runs the example again and publishes that execution, and a write repair publishes the same execution without running the write again; after an applied output change either publishes the same execution again. In maintenance, `contract_output_mismatch` now tells the minter to keep a registered field and fix the extraction, or to propose the output change, not to make the field optional.
- A host that publishes repairs adopts this by implementing `taskUpdateConfirmer`, keeping applied output changes with the rest of the task state, and comparing the registered output schema with the repair's at publication. It refuses a loosening as `output_obligation_weakened`, exempting only the field and change an applied output change names. Core ships no comparison, because the local host publishes no repairs.
- A misplaced secret handle's refusal now tells the minter to write the handle as the whole string literal in the Playwright code of a `kernel.browsers.playwright.execute` call.
- `exampleInputRefusal` takes an optional `maintenance` flag. A host sets it while it repairs a published tool, which runs its failing case's own input, so `exampleInput` is refused. The local host never sets it.
- New exports let other hosts drop their copies of these checks.
  - `pomerado/core/mint/step-checks` exports `testInputNotJson`.
  - `pomerado/core/mint/publication-review` exports `unlistedExampleInputKeys` and `exampleInputFeedback`.
  - `pomerado/core/mint/draft-questions` exports `draftQuestionDeclarations` and `draftQuestionDeclarationFailure`.
  - `pomerado/core/execution/declared-questions` exports `asksAsDeclared`.
- `pomerado/testing/shop-fixture` adds a storefront for evaluating search and cart tools. `/catalog` is a search whose size, color and fit filters sit in a panel behind an "All filters" button, offers only the choices the query's results have, shows each applied filter as a removable chip, and says so when nothing matches. `/product` asks for a product's options before adding it. The guest cart and the account cart are separate, and the account's cart starts with one line. Checkout needs the account, holds back an order under `orderMinimumMinor`, and asks for a shipping address when the account has none saved. `storeProducts` lists the catalog, and the shop's state holds `guestCart`, `accountCart`, `savedAddress` and `placedOrders`.
- The package adds a `search` skill, loaded after `core`, and a `cart` skill, loaded after `writes`. Neither has sections.
  - `search` is for a search or listing tool. It takes the site's own filters, sort and location as inputs, sets each through the site's control and reads it back, and returns an empty list for a search the site answered with no results. A filter that did not apply fails the run, and a value the page does not offer throws `InvalidInput` naming the choices it does offer.
  - `cart` is for any tool that reads, adds to, changes or checks out a cart. It signs in first, reads the cart before and after a change, states whether quantity adds or sets, and throws `InvalidInput` with the site's reason when the site refuses the order as asked, such as an order under its minimum.
  - `AGENTS.md`, the writes skill and the core skill's `core.references` text point to them. A host that composes its own `core.references` text names them there.
- The core skill states the output rules in one place. A value the request needs is required and non-null. Every output is read from the page or response on every run, never a literal or a constant. `null` or an empty list means the page lacks the value, and a value the code cannot read throws `OperationFailure`. The input schema rules add that the schema never promises an input the code accepts and then ignores.
- `AGENTS.md` asks the minter to read back every input before returning, applied filters, sort and selected options included, and to fail the run when one did not apply. It no longer offers flagging a mismatch instead. A link the site offers is opened by its exact `href`, never trimmed or rebuilt.
- The auth skill never lists or picks a passkey, even when the caller asks for one. It declines optional setup offered during sign-in, such as creating a passkey, as its own fieldless step, opens only the pages the task needs once signed in, picks a sign-in method in a fixed order, and records the site's own sign-in link by its exact `href`.
- The shared skills give one rule for when to ask the caller, the one in `AGENTS.md`, and the forms and writes skills point to it and to the core skill's input schema rules instead of restating them. Tool descriptions briefly state their design decisions, limits and interpretations.
- The minter's `execute` tool description and its credentials notice no longer mention Kernel Managed Auth, which no host offers.
- A signed-in check whose sign-in sent the login only to origins off the site and its sign-in origins still fails `credentials_not_submitted`, and still counts nothing sent there. Its result now lists, in `untrustedSignInOrigins`, the origin of each `fetch` or XHR request other than a GET whose address or body carried every value the screen filled, as an exact origin with no path. An origin it already lists also counts a later screen's values its own requests carry, as an identifier-first sign-in sends them one screen at a time. It lists an origin only while a value that origin heard doesn't count as sent yet, and when some of those received the password or a code, only those. With none to list, it fails as it did before.
- A local mint that doesn't publish lists those origins in its outcome's `untrustedSignInOrigins`, even when no check ran, and so does the output of an incomplete `mint` job. `finish_build` names them too when it refuses as `autofill_recipe_not_verified`, and so does the outcome's summary. Add one you trust to `authenticationOrigins` and mint again. The new `LocalMintOutcome` type from `pomerado` is what `mint` returns, `MintOutcome` with that field.
- The local minter asks the caller once whether to trust the origins a signed-in check found the login sent to, when there are one to three and each is an https origin off the site it hasn't asked about. The question is the host's own `trust_sign_in_origin` confirm, which Guardian doesn't review.
  - Until the sign-in has sent a password or a code anywhere, the site included, it asks only when there's one. A check made before the password screen, when the email went to an identity service and to an analytics script, asks nothing. The check after the password screen asks as before, and once the password reached the identity service it names only that one. One origin that heard only the identifier is still asked about, as a sign-in by approval or email link sends nothing else.
  - A yes trusts them for sign-in only, counts what the sign-in sent there and checks again without typing anything. Guardian's allowed origins stay the request's.
  - A trusted origin stays in `untrustedSignInOrigins` until a sign-in verifies, since nothing saved it, and the summary then says to pass it up front.
  - A sign-in that sends the identifier to such an origin and then the password to the site in a script's request without the identifier verifies only when that origin is passed in `authenticationOrigins` up front. One whose password screen posts its own form to the site verifies after a yes.
  - A no ends sign-in in the build as `sign_in_unavailable`. `SpentSignIn` adds `sign_in_origin_untrusted` for it. An unanswered question ends the build unanswered and trusts nothing.
  - A published sign-in saves the build's https sign-in origins in `pomerado.json` as `signIn.authenticationOrigins`, the ones passed in `authenticationOrigins` first and then the trusted ones. A build with no sign-in origins saves the same bytes as before. `deployment.json` adds them to the request's `authenticationOrigins`, and a run signs in through both. `MintArtifact.signIn` gains the optional `authenticationOrigins`.
  - An earlier version ignores the origins `pomerado.json` saved. Its served calls still sign in through `deployment.json`, and its `pomerado run` of such an integration fails to sign in.
- `pomerado/testing/shop-fixture` adds `identityHost` and a sign-in at `/identity-login`. Its script sends the login to an identity service on that host, then trades the token for the shop's session. `/identity-steps` is an identifier-first sign-in on one page. Its first screen sends the identifier to that service, and its second sends the password there, or to the shop with `?password=site`. With `?analytics=on` its first screen also sends the email to an analytics service on `analyticsHost`, and the shop's state counts those posts in `analyticsPosts`. `/account/note` saves a note for the signed-in account. The shop's state counts `identityPosts` and keeps `accountNotes`.
- A Guardian review's 120-second deadline (600 for a development public read) no longer counts the time the provider spends compacting the conversation. Each model call whose response compacts it moves the deadline later by its duration. A compacting call still running at the deadline is cut off with the review.
- Guardian's publication policy gives a loosened needed value its own rule. A needed value is an output fact the request names, the record's identifier or context those depend on. Its field must be required and non-null, whatever its description says; it may be null only where that record's page does not show it, with a required field beside it saying why. Source that turns a failed read into null is the same finding.
- The policy adds a lost-information rule: a fact each record or result shows that the output drops, or a value it trims or splits and drops part of. An input may be left out only when the site has no control for it; a description naming it as left out no longer excuses it. A field the code reads from each record's own element is supported even where the example's record lacked the fact, and narrowing a claim is never the fix for an output the page shows.
- `pomerado/runtime` adds `outcomeWaitCode`, page code for a Kernel call body like `formControlsCode`. Its `waitForOutcome(outcomes, { action, timeout, unchangedMs })` waits for whichever of the page's possible answers shows after a step such as a search, a filter, a date pick or a submit, named one locator each (`{ failed, unavailable, empty, results }`), and returns that key. It only observes, apart from running `action` once.
  - The first listed outcome wins when several show, so a site's error, a refusal or a greyed-out choice listed first wins over results beside it. It answers once two looks in a row agree.
  - `action` is the step itself. What an outcome showed before it, the same element with the same text, counts only after staying so for `unchangedMs` (2 s by default), so results a filter has not yet re-rendered are not read, and a filter that leaves the same results still resolves. A new or changed element counts at once.
  - It throws an `Error` named `OutcomeWaitFailure` with `reason` and per-outcome `observations` (`OutcomeObservation`, a count of matches, of visible ones and, after an action, of changed ones), and a message naming both: `outcome_ambiguous` when the winning locator matches more than one element, which it never picks among, and `outcome_timeout` when nothing showed within `timeout`, 30 s by default.
  - The core, forms and search skills tell the minter to name every way a step's page can answer and wait with it, rather than only for the happy result. The navigation reference waits for its search's answer, its record's page and its verification page this way.
  - Other hosts get it from `pomerado/core/browser/outcome-wait`.
  - A run whose `waitForOutcome` saw no outcome in time fails as `BrowserActionTimeout`, as a native Playwright wait's timeout does, so a host keeps the browser and reports it as a browser action timeout. `outcome_ambiguous` stays the tool's own failure.
- A script's context adds `askOne(id, question)`, a thin wrapper over `ask` that asks one declared question and returns that answer itself. `ask` with a list or an object returns one answer per id, such as `{ seat: "12A" }`, so the caller-input skill now says to read `answer.<id>` and names `askOne` for one question. `pomerado/runtime` exports its type as `ScriptAskOne`.
- The core skill tells the minter to prefer waiting, after a search or a filter, for the site's own sign that this load finished, such as a spinner that showed and went, or a result count that updated, before reading results. A list that fills in as it loads, or an old list that stays up before a reload, can pass the outcome wait's unchanged check.
- A write can confirm from its own commit request. The writes, forms and core skills tell the minter to keep the click on the final commit control in its own step and, in the same call, wait for the site's response to the request that click sends, matched by its method and path and by its body where the body shows the caller's values. The write went through when that response is 2xx or 3xx, a body the call can read shows no error, and the page shows no error or validation message after it. A 200 whose body reports an error, as GraphQL can, did not go through, so the write isn't confirmed. A 202, or a 2xx whose body says the work is queued, counts too, and the output carries the site's own status word for it. The step then reads what the output promises from that response or the page the commit left, calls `verified()` and still declares `readback`, and opens no other page only to prove the write.
  - It reads the site back only when the request can't settle the write: no such request went out, it failed, got no answer or returned an error status, its body shows an error or can't be read on an endpoint that reports errors with a 200, the page shows an error, the commit went over a websocket or a GET link, or a later stage the site can still refuse sent no request of its own. A generic toast alone, or a 200 from another request, confirms nothing.
  - A failed step may confirm from the page as it stands, after checking it for an error, when `stateChangingRequests` shows its commit request went through. Showing that a write did not happen still takes a read-back.
  - The outcome reviewer counts that commit request, listed in the step's `stateChangingRequests` with a 2xx or 3xx status and no error after it, as evidence the write is `done`. A 202, or a 2xx whose body says the work is queued, counts too, and a 200 whose body reports an error, as GraphQL can, did not go through. A commit step with no commit request recorded is an example of `unknown`. Guardian's publication policy accepts a composed script that confirms this way, and makes a script that accepts any request or status, takes an unchecked 200 from an endpoint that reports errors in its body, or skips the page's error check a confirmation finding. Guardian's execution policy says that when a write's step shows its commit request went through, with no error after it, reading the page as it stands is the read-back it asks for, and another page is not needed.
  - The core skill describes each `stateChangingRequests` entry's `statuses`, its requests' final response statuses in order, and `unanswered`, the count with no answer when the step ended. A host that lists state-changing requests must record the commit request's response status there. Without it the minter reads the site back as before. The local host keeps no such list, so only the script's own check applies there.
- The core skill tells the minter to prefer waiting up to 15 s after applying a filter for the results to filter, and to return once most of the rows pass. After 15 s the tool returns what is there: it doesn't fail and drops no rows. The search skill's rule that a filter that did not apply throws `OperationFailure` stays. It checks the control's own read-back, and this line checks the rows after one.
- The core skill tells the minter to prefer typing into the search box again when its suggestions don't appear after a step that reloads the page, such as choosing a city.
- The core skill tells a tool to start an obvious refusal's message with "Caller input error:", so a host that ends such a refusal at once can give the caller the answer without a repair. A refusal is obvious when the input alone breaks a rule of the task, checked before any site action, such as a departure date before yesterday in UTC, a return before its departure or a count below one, or when the page refuses the value in its own words, which the message quotes. It is never obvious when the tool's own read found nothing, such as an empty suggestion list, a control that had not loaded or a day a write finds disabled without the page saying why. A read returns a greyed-out day as unavailable data.
  - The forms skill points to it and counts a date as past only before yesterday in UTC. The caller-input skill names a near-miss name the site offers alternatives for as ambiguous, and prefers not starting its refusal with it. A greyed-out day or option is never ambiguous: it follows the core skill's unavailable-option rule. The `InvalidInput` doc comment says which refusals a host may end at once.
  - The local host gives the start no special meaning; it is part of the failure's message.
- Guardian and the minter turn safety defaults off. A safety default is a preselected option whose only effect is sharing the caller's data with another company, such as a partner comparison that opens the search on another site, opting into tracking beyond what the site needs, or signing the caller up for marketing email.
  - Guardian's execution policy says turning one off invents no choice and needs no caller input or answer. Keeping one on is what needs a reason: Guardian denies source that submits with one on unless trusted intent, an answer or the input asks to keep it, or the site refuses to submit with it off. It never covers an option that changes what the caller gets, such as which results come back, a seat, a room or a price. The write-options rule, which settles an add-on, a pre-selected paid option or an unexpected commitment on a write's path only from the input or an answer, excepts a safety default.
  - `pomerado/core/guardian/publication` exports `publicationSafetyDefaultPolicy`, and the core publication policy includes it. Such source is part of a good tool and never an input, example-value, schema or claim finding. A current source that drops or weakens one an earlier copy set is a `safety_default` finding. A write's options must be inputs, except a safety default.
  - The core skill tells the minter to turn each one off on every run before the submit it affects, read back that it is off, leave it on and say so in the description when the site won't submit with it off, and name the ones it turns off in general words. A repair keeps each one. The minter finds them by listing every checkbox, switch and toggle near the form by role and by `input[type=checkbox]`, unlabeled ones included, and checks after a probe's first submit whether a new tab opened or the page left the site.
  - The search, writes and workspace guidance never asks about one or makes it an input. The publication skill's rule against setting a consent, marketing, tracking or privacy flag now says to turn safety defaults off and never turn one on. The forms skill prefers a cookie banner's control that declines optional cookies.
- Guardian's execution policy treats accepting the terms a site requires to finish the requested action, such as a required "I agree" box at checkout or a notice that signing in accepts the site's terms, as part of that action, with no other authority. Terms the action doesn't require, such as a partner's terms or a marketing consent, are not. Terms on a sign-in screen no longer need authority in trusted intent; remember-device and other lasting account preferences still do.
- The forms skill tells the minter to prefer matching an existing record by a fuzzy match on its name, as the core skill says, and to prefer never picking an "Add new" row when an existing record matches, so a picker doesn't create a near-duplicate of a record whose name differs from the caller's only in case or in a usual form of the same name.
- Guardian's publication policy asks the review to list every finding it sees in the bundle, not only the first, so the minter can fix them together. A publication review now has 300 seconds, up from 120 (earlier 0.4.0 canaries gave it 240); other reviews keep 120, and a development public read keeps 600.
- `SiteHttp` names the rule a request broke when it refuses it before sending. The failure's new optional `refusal` holds `rule`, one of `HttpRequestRule` (`request_invalid`, `url_not_absolute`, `url_has_credentials`, `url_has_fragment`, `method_unsupported`, `body_on_get_or_head`, `header_name_invalid`, `header_value_not_text`, `header_value_newline`, `timeout_invalid`, `max_response_bytes_out_of_range` or `capability_unsupported`), and the header or the capability and transport it was about. Its message says "refused by the request check, nothing was sent", the rule and how to fix it, and leaves the URL's user:password, query and fragment, and any header name or capability that is not a plain identifier, out of the message. `pomerado/runtime` exports the `HttpRequestRule` and `HttpRequestRefusal` types. The codes stay `invalid_request` and `unsupported_capability`, with dispatch `not_sent`, except that an unknown capability string now fails `unsupported_capability` where it failed `invalid_request`.
- `http.request_started` names `page-fetch`, with reason `page_environment_required`, for a request that requires `page-environment` or `service-worker` on a live transport. It named the host transport, such as `kernel-curl`, for every request.
- The http-mcp skill opens with the request rules, and no longer tells the minter to raise `maxResponseBytes` for a large body or to declare `buffered-response-v1` with it.
- `finish_build` takes an optional `httpVersion`, `{ outcome: "ruled_out", signal, requestId?, note }`, for a read published without an HTTP version: the signal is one of `HttpVersionSignal` (`per_request_hash_or_page_id`, `bot_wall_on_page_fetch`, `unobtainable_session_token`, `streaming_response`, `location_not_applicable` or `site_refused_on_both_transports`), `requestId` the captured request it rests on and `note` what showed it. The harness screens the note like `coverage` and passes the decision to the host's `publish` as `PublicationRequest.httpVersion`; the host decides publication from its own records. `HttpVersionDecision` and `HttpVersionSignal` are exported from `pomerado/core/mint/contracts`. The harness refuses it on a write build as `http_version_on_write`, before publication. The `http_implementation_untested` instruction asks for this field instead of a deleted file, has no limit on HTTP tests, and says a request refused before sending never counts.
- `preflightTestInput` treats a live test of a `*-http.mjs` entrypoint like one of the Playwright version: an HTTP version is fixed and tested again until it matches. The local host refuses a Kernel script in a `*-http.mjs` file before it runs, as hosted hosts do.
- The http-mcp skill is rewritten for reads: find where the example's data comes from, starting with the example page's own document, then its data request, then a POST query; the signals that rule an HTTP version out, given as `httpVersion`; the parsing helpers; `InvalidInput` with the site's choices when the site refuses a caller's value; testing after each fix with no budget, reading failed answers, trying the page's fetch after a wall; and parity rules, under which order and ranking differences are notes, a missing field is a bug, and an input or location the HTTP version can't apply rules it out. Maintenance repairs the HTTP version instead of dropping it. The search skill says an HTTP version reads each input back from the answer, and the testing skill that a failed HTTP test is fixed and run again.
- The HTTP version reference shows a site's refusal of a caller's value failing as `operationErrors.InvalidInput` with the input field and the site's choices.
- Guardian's execution policy counts a read's HTTP version that sends the page's own signed-out search-state save, a PUT or POST included, before its query as part of the read.
- The writes skill and the workspace guide say a refused publication keeps live execution on the same browser, still signed in, so the minter reads `page.url()` first and prefers not to sign in again. Only a publication whose capture failed leaves a fresh browser on a new, empty profile. The `http-mcp` skill says a refused publication does not skip the HTTP-version ask, and the ask's own message no longer says it comes only while live capture is open.
- The core skill and Guardian's execution and publication policies say a tool matches the caller's proper nouns, such as places, venues and company names, with a fuzzy match that accepts the usual forms of the same name, never an exact one, and lists the options for the caller instead of picking one when more than one matches. Another usual form of the same proper noun is not a near match, the workspace guide counts matching one as work the request already covers, and a read-back compares a proper noun with the option it matched.
- The search skill says that when the page's list of choices does not hold a caller's value but a broader choice such as "Show all" covers it, the tool chooses the broader choice and returns the rows the site gives, saying so in the description; otherwise it refuses with `InvalidInput`. The core skill allows that broader choice on a search, and the workspace guide's read-back rule returns its rows with what applied. A filter the site has a control for is set through that control, never by filtering the returned rows, and Guardian's "Applied without readback" publication finding covers only inputs the site has a control for.
- Guardian's execution policy counts searching with the site's broader setting or its default as a routine implementation choice when the site's form has no setting for a request constraint, such as a cabin class with only "Show all".
- The auth skill says that on a one-time-code screen the minter prefers one read that finds the code fields, the submit and any remember-this-device box, then sends the code step at once, before any other probing, since codes expire in minutes.
- The core skill tells the minter never to search the open web for the page a task needs, but to make its URL an input and ask the caller for it.
- The writes skill tells the minter to prefer marking the commit at the step that submits the booking or order. A hold that expires on its own, such as a reserved table or a cart timer, is not the commit, and its step is not marked.
- Guardian's publication policy says a repair's review prefers denying only for lines the repair changed, or for unchanged lines that a failing run or example shows broken, and notes other doubts about unchanged lines without denying, except a privacy or credential finding. It is part of `publicationLiveTestsPolicy`, so a host with its own publication policy that includes it gets the rule too.
- Guardian's task update policy says the host, not the agent, sets `update_review.effect`: for a write build no change needs to make it a write, and the confirmation need not cover the write. It also says a task update review's empty `trusted_authority.allowedEffects`, like the read-only `allowedEffects` of earlier exploration reviews, says nothing about the build's effect.
- Guardian's execution policy, beside its sign-in screen rules, and `publicationSafetyDefaultPolicy` say to prefer leaving a site's own "Remember me" or "Keep me signed in" choice at its default on the tool's own sign-in: it keeps the account owner's session, which later runs rely on, it is not a safety default, and neither review denies the host's own sign-in step over it.
- Guardian's task update policy, its execution policy, the `mint_update` tool description and the workspace guide say an update never overturns a Guardian decision, except that the caller's confirmed answer can overturn one that held a step to their own request, such as a time, a value or a search setting. A caller's answer never overturns a decision made for safety or for a Pomerado scope limit.
- The caller-input skill says `ask` returns one answer per question id only with an array or an object of questions. `ask("id")` with one id returns that answer itself, as the line before it says.
- The writes and forms skills tell the minter to prefer confirming a write from what the page shows after the commit click, such as an order or reference number, or a success message or toast that appears after the click with no error on the page, and to open the saved state, such as an orders page or a booking list, only when the page shows no confirmation. A commit step that returned without calling `verified()` while its `stateChangingRequests` list the commit request with a 2xx or 3xx status prefers confirming it in the next step from the page as it stands. A composed script prefers confirming from that commit request in the commit call over opening the page the session confirmed on. The local host's standalone write completion text says to read back committed state only when neither the commit request's response nor the page confirms the write, and its Guardian publication note says `unverifiable` is valid only when the site offered no commit response the script can check, no confirmation and no read-back.
- The `write-readback.ts` reference confirms its write from the create request's 201 and its Location, calls `verified()` at once, and returns only the new task's id, taken from the Location. It no longer opens or reads the page that follows, so a slow, missing or stale detail page no longer fails a write the 201 confirmed. The Location may be a path or an absolute URL on the response's own origin, and its path must be `/tasks/` followed by one id. Any other Location, such as one on another origin or with a trailing slash, fails as `not_saved`. The output schema of the `pomerado/authoring/write-readback` export is now `id` alone, without `title` and `assignee`.
- A 201 whose Location names the new record confirms a write as soon as it arrives. The writes skill says such a write went through with no wait for the page, the forms skill says it needs no page error check before `verified()`, and the publication review's write rule says it needs no page check, so the `write-readback.ts` reference confirms without one. A recorded publication review keyed on the exact policy text needs recording again.
- The workspace guide says a write build reads back whether its earlier commit took effect, after a refused publication, only when that commit recorded no confirmation. A commit that recorded its confirmation stays done.
- `chooseOption` from `formControlsCode` matches an option's label or value ignoring case, spacing and accents, and apostrophes and the punctuation `.`, `,`, hyphens and dashes except next to a digit, so "Abaca" chooses "Abacá", "St Louis" chooses "St. Louis" and "Saint Denis" chooses "Saint-Denis". Its last rank now picks a label that holds the wanted name as whole words, so "Acme insurance" chooses "Acme insurance Customer". Two options that then match at the same rank, such as "Abaca" and "Abacá", or two labels that both hold the name, are refused as `option_ambiguous`. Other symbols, such as `+`, `#` and `&`, still count, so "C++" never chooses "C", and a number keeps its sign and separators, so "-5" never chooses "5", "5'10" never chooses "510" and "1.5" never chooses "1-5". A value of punctuation alone, such as "-", is compared as it is, so it never chooses an option with an empty label.
- The core, writes and forms skills and the workspace guide say name matching and read-back comparisons ignore accents too: typeahead lookups ignore accents and spacing, the usual forms of a proper noun include it with or without its accents, the Confirm step and the workspace read-back rule ignore accents and punctuation such as periods and hyphens, the pre-commit check on a write compares values the same way, and the forms skill says what `chooseOption` folds.
- A choice question's own text that repeats an offered option now picks it apart from accents and inner spacing as well as case and surrounding spacing, so a typed "Abaca" picks the offered "Abacá" instead of counting as the owner's own answer. A bare option id still never counts.
- The output check flags the same item twice in one list and fields no tested run filled, both advisory. A record ID, SKU or link field (such as `id`, `sku`, `url` or `product_id`) that repeats within one list of two or more records is reported as `duplicate_entries`, such as a sponsored copy of an organic result; no new check name is added, so every release decodes the findings a live test record keeps. `lintOutput`'s new option `alsoTested` takes the `fieldFill` of the tool's other tested runs on the same source, paths and counts with no value (`fieldFill` from `pomerado/core/runtime/output-lint`): a field empty in every record of the run and of those runs, at least one of which holds it, is flagged `empty_field` outside a list even in one record, as a detail field read from a collapsed section or a guessed key, and in a list once the runs hold three of its records. With no other tested run, only the per-list check runs, so a single build or hosted run is never flagged for a null detail field. The list paging fields are never flagged empty.
  - The harness passes each live test case the other cases' fills on the same source, and gives `publish` every case's fill as the new optional `hostEvidence.testedFields`, which no checkpoint holds. `outputNotes` takes it as `alsoTested`; the local host passes it, so `publication/output-notes.json` flags an example's field no tested run filled.
- The pagination, search and core skills return each item once. A row's key is the item's own stable ID, never its link text or position, and the skills no longer give a sponsored copy its own key so both stay. When the site lists the same item twice, such as a sponsored copy of an organic result, the tool returns the organic row at its organic position and drops the copy. A promoted row whose item the page lists only as promoted stays in place with `sponsored: true`, and a promoted carousel or banner with its own heading is not a result. The search skill asks the minter to list a typical query's item IDs before the first example and check that none repeats, to read the applied query from the page's embedded state, to fetch a per-result extra in one batched request, and to test a broad query and a fallback or "no exact matches" query whose expectation it writes after seeing the site's answer.
  - `ListReader` and `selectRows` take an optional `promoted`, whether the site marks a row sponsored. `readList` and `selectRows` then drop a promoted copy of an item the rows read show unpromoted, or an earlier page returned, without setting `list_changed`, and remember a returned promoted row apart from the item's organic row, so the organic row a later page shows is returned rather than counted as a change: the one repeat left is a sponsored copy returned before its organic row was read. A promoted row that ended the previous page anchors the next as any row does, and `finishList` takes `resumeAfterPromoted` for a call that returned no rows and resumes after one. Without `promoted` they behave as before. The pagination reference example keys rows by ID and passes `promoted`.
- The core skill says descriptions, specs, ingredients and variants often sit in collapsed sections that read empty while hidden: prefer the page's embedded record data, or open the section and read it back, and never guess a data key with a null fallback. Before the first example, the minter sees each nullable field filled on a record that should have it, bases an absence reason on evidence that the record lacks the field, and names in `finish_build` coverage a tested record where each nullable field was filled. A tool sets up its own start state from a cold page, such as a guest session, a chosen location or a consent banner.
- The testing skill plans the cases builds most often add late before the first batch (no results, a broad query, page two, and one case per selectable variant such as a second store), runs no batch before the example passes, observes a no-results query before writing its expectation, and after an edit reruns only the cases the edit can affect.
- `waitForOutcome` from `waitCode` and `outcomeWaitCode` no longer counts an answer that was on the page before its `action` while a request the action started is still in flight, as well as for the first `unchangedMs`. A filter whose answer came after the 2 s window used to return the list from before it; the wait now returns the redrawn list. A step that starts no request, or whose request ends within the window, ends as before. A request the action started holds the earlier answer back for at most `lateFillCap` (15 s), and never past `timeout` less `unchangedMs`, so a request that never ends, such as a long-poll or a stream, delays an answer the wait used to return but never turns it into `outcome_timeout`.
- The core skill asks for `waitForOutcome` after a step that redraws part of the page, such as a pick from a list or adding a table row, as well as after one whose answer can vary, naming the element the next step uses beside the step's other results. It prefers no fixed pauses unless necessary, and asks the minter to check that the tool handles a lookup or filter that matches nothing. The writes skill says the composed script runs a session's steps back to back, without the pauses taken between them, so a step that redraws the page, such as a filter, a pick or a new table row, should end with `waitForOutcome` naming the element the next step uses.
- `waitForOutcome` from `waitCode` and `outcomeWaitCode` answers at the first look that shows an outcome, where it used to wait for a second look, taken at once, to agree. A page already showing its answer now costs one look instead of two, and its `waitReport()` summary says "1 look". An answer that was on the page before the `action` is still held back for `unchangedMs` and while a request the action started is in flight, a quiet page still needs two looks to fail as `outcome_unknown`, and a winning outcome that matches more than one element now fails as `outcome_ambiguous` at the look that sees it. A look that began while such a request was in flight holds the earlier answer back even when the request ends during that look, so a slow answer that redraws the list just after it ends returns the redrawn list. A look that answers takes no progress sample, so the summary's progress may end one sample earlier. Each look reads the outcomes in reverse of their listed order, so the highest-priority outcome is read last: an error the page draws in the same render as partial results wins over them, even when that render lands between two reads of the look.
- The core skill prefers no result wait after a step that changed nothing, such as closing a panel without picking anything, and no extra wait for the same answer after `waitForOutcome`, which already waited for it.
- The core, caller-input and forms skills count a date as past when it is before today in the site's time zone, in place of before yesterday in UTC. A site with places in several time zones uses the place's zone, such as a restaurant's or a departure airport's, when the tool knows it before any site action, and when it doesn't know the zone, it refuses only a date that is past in every time zone, such as one before yesterday in UTC. The core skill notes that UTC's date can be a day ahead or behind. A tool that compared with today's date in UTC refused a date that was still today where the site is, for several hours each evening in the Americas.
  - Guardian's `publicationOutputPolicy` adds the "Past date in UTC" rule, a source-correction finding: source that refuses a date as past by comparing it with today's date in UTC, rather than today in the site's time zone or the place's, unless the site's own dates are in UTC. Refusing only a date before yesterday in UTC, which is past in every time zone, is not this finding. The publication skill's edge-case checks name it. A recorded Guardian response keyed on the exact policy text needs recording again.
- The testing skill gives every free-text input of a read signed out three cases of its own in a build: a blank value, an over-long value and a made-up value the site has no match for. A repair adds only the made-up value, so it never tightens a published input's bounds to pass the others. A blank value expects `invalid_input` when the input is required, and an optional input may treat it as left out; the over-long value expects `invalid_input` from the input schema; the made-up value expects `invalid_input` naming the field, `empty` for a search query, or a labeled `result` for a location the site won't apply, and none may end in another throw. An input that takes a person's, account's or record's name, number or code skips the made-up value, and the other cases still use real values the site offers. A blank or over-long value the input schema refuses may expect `invalid_input` beside the inputs the site has no results for, does not offer or cannot apply.
- The core skill's refusal recipes name the input: `new errors.InvalidInput(message, { field })` for a value the site refuses, and `field` beside the page's own words for a not-found record and in the waits paragraph. The `navigation.ts` reference passes `field` on each refusal.

### Fixes

- A build's read-or-write question no longer dead-ends when Guardian's question review rejects it. That turn offers no other tool, so a minter that withdrew the question, as the host's instruction allowed, ended the build with no tool. For that question, `question_rejected` now tells the minter to reword it and call `request_input` again, and says the host sets its two answer labels, so only the prompt changes. Every other question keeps the reword-or-withdraw instruction.
  - Guardian's rule for the read-or-write question says the host requires it and sets its answer labels, so the review judges only the prompt and prefers allow when the prompt plainly says what the tool would do, even when trusted intent already leans one way. A prompt may say that a write build does the requested task once, for real, while it builds.
  - A recorded Guardian response keyed on the exact policy text needs recording again.
- Guardian's question review now knows the build's effect, so it no longer rejects the true statement that a write build publishes only after it does the requested task once, for real. Its `allowedEffects` stays empty on purpose.
  - The harness passes the decided effect to `MintDependencies.reviewQuestion` as the new optional `buildEffect`, `read` or `write`, when it reviews the minter's questions, its blocked report and its stop text. It is absent on the read-or-write question's turn.
  - `questionForReview` and `PendingQuestion` in `pomerado/core/guardian/question` take the optional `buildEffect`, and the review reads it as `question_review.buildEffect`. A host that builds its own facts for `questionForReview` forwards it; one that doesn't leaves it out, as before. The local host forwards it.
  - A recorded Guardian response keyed on the exact policy text needs recording again.
- Guardian's `new_mint` on a `mint_update` the minter recommended as `update` no longer ends the build. The host returns it as Guardian's `clarification_required`, with the rationale, and the minter asks the caller to confirm the change. Such an ending used to tell the caller to start a new build for the task they asked for, often with no suggested request to send. Only the minter's own `new_mint` recommendation, which needs a `suggestedRequest`, now ends a build as `new_mint_recommended`.
- The workspace guide says a build can't ask for a file. When the task needs one the request doesn't carry, the minter says so in `report_blocked`, naming the file the owner should attach when they build again. A composing host keeps the line, since it sits outside every host section.
- The publication record `publication/tests.json` no longer lists an HTTP version whose `src/tool-http.mjs` was deleted after its `live_tests` batch ran. It took the HTTP version's entrypoint from that batch's results whether or not the file still existed, so a deleted version that does not ship still went to the review, which could judge its untested capabilities as gaps no further test could clear. The record now lists the HTTP version by `src/tool-http.mjs` while the host's `pathExists` finds that file, and leaves it out when it doesn't, so a scratch `*-http.mjs` the latest batch ran, deleted or kept, no longer stands in for the version that ships. A host without `pathExists`, or whose check throws, keeps the file the latest results ran, as before.
- An honest read whose site shows no results for a tested input can now pass publication review. Its minter may change such a case to expect `empty`, and review no longer counts that as hiding a failure, nor as a case that tests nothing, when the captures show the site's own answer for that exact input, such as its no-results page.
  - Each retired entry in `publication/tests.json` adds the optional `changedExpectationBy`: a case that passes the same input with another expectation on that version's published source. The host excuses nothing by it; Guardian's `publicationLiveTestsPolicy` excuses the failure only when a capture shows the site giving the new answer for that input, on a page reached through the site's own controls or a URL they produce that reads the input back as the site applied it, never a challenge, error, sign-in, blocked or loading page, and the case's purpose or the coverage text names that capture.
  - A case that expects `empty` where the captures show the site's own empty state for that exact input tests the empty result. One that expects `empty`, `error` or `invalid_input` for an input the captures show results for still tests nothing.
  - Guardian's "Unapplied supplied input" rule says that with no results a sort has nothing to apply: the tool returns the verified empty result, never `InputNotApplied` for it.
  - A finding about `publication/tests.json` keeps its ordinary reason, such as `source_correction` or `evidence`, and goes back to the minter: a publication decision with reason `host_owned` and a finding in that file fails to decode as `InvalidDecision`, as one in `publication/definition.json` does. A `host_owned` denial in any other host file still ends the attempt as the host's failure.
  - The publication skill adds an edge-case check before `finish_build`, naming the review rule each miss comes back under. The testing skill says when a case's expectation may change, and the core skill says to read each page's fields in one call, since each call on a hosted browser is a remote round trip, and to prefer list data or the site's own data request to opening every record's page.
  - A recorded Guardian response keyed on the exact policy text needs recording again.
- Login parameters in hash-routed callback URLs are now detected correctly. `oneTimeLoginUrlParameters` from `pomerado/core/mint/login-url` parsed the fragment as a whole, treating a route path before its query, such as `/#/oauth/callback?code_challenge=…`, as part of the first parameter name instead of reading the query following `?`. A fragment of parameters alone is still read as a whole, so a `?` inside one of its values, as in `#SAMLRequest=…?…`, keeps that parameter.
- A URL now ends where a credential or a structural closer begins, so a credential written right after it is screened like any other text. `urlSpans` from `pomerado/core/privacy/url-spans` ran a URL to the next space, quote or angle bracket, so a field glued to it by `,`, `;`, `|` or `)`, as in a CSV row, a pipe table, a Markdown link or a `url=…;password=…` list, counted as part of the URL, and `redactDiagnosticText` from `pomerado/core/runtime/failure-detail`, which leaves URLs byte-exact, kept a credential there readable: `see https://portal.example/a,password=Synthetic1 now` kept the password. A URL now also ends at an unbalanced `)`, `]` or `}`; a backslash escape other than `\/`, `\u` or `\x`; a character reference to a double quote or an angle bracket, such as `&lt;`, `&quot;` or `&#x22;`, or one escaped again for markup, such as `&amp;lt;` (an apostrophe is a URL character, so `&#39;` doesn't end one); and a `,`, `;` or `|` whose next field starts with a credential-named `key=` or `key:`, a bearer or basic credential, an AWS access key ID, a provider API key or a JSON Web Token, in its path, query or fragment alike. A `;` that closes any other character reference, such as `&amp;`, `&nbsp;` or the chained `&amp;amp;` or `&amp;#x26;` of markup escaped twice, is no delimiter. A real URL stays whole, including lists of dates, numbers, addresses or names in its path or query (`?dates=2026-01-31,2026-02-07&otp=…`, `?ids=1,2,3`, `/flights/SFO-JFK/2026-01-31,2026-02-07`), a matrix parameter (`;v=1`), a `|` anywhere but before a credential, a URL in a CSV row, balanced parentheses (`/wiki/Foo_(bar)`, which used to lose its `)`), percent-encoding, JSON-escaped slashes and nested redirects. A scheme-relative candidate needs a host both as written and within the URL it ends as, so text past its end (`//token.`) can't make it a URL. The scan stays linear. Spans are now disjoint: a URL found inside another never extends it.
  - 0.4.0 canaries from `0.4.0-canary.154` also ended a URL at a `,`, `;` or `|` whose next field held an `@`, a long number, a date or a capitalized name, at a `,` outside the query that started any `key=`, at a `|` outside the query, and at the `,` or `;` written just before the URL. Those rules ended real URLs mid-query, leaving a later parameter of the URL, such as a one-time code or an API key, to a host's own screening outside URLs, so they are gone. They also ended a URL before some credential forms, a `password:value` field and a bearer value followed by punctuation, which the credential rules above now catch. A bare CSV or pipe field after a URL, which core does not screen, is inside the URL again, as before those canaries.
  - The new `urlSpanAt` ends a URL or path that starts at a given offset by the same rules. `redactDiagnosticText` uses it for a route at the start of a message, which used to run to the first space: `/cb,password=Synthetic1 failed` kept the password.
  - `redactDiagnosticText` also redacts a credential-named `key=` value written after `|`, `)` or `]`, as it did after `,`, `;`, a space, a quote or an opening bracket: `a|api_key=… b` kept the key.
  - The new `urlReaches` returns how far each URL reached before, to the next space or quote. It is no screening exemption. The failure detail schema measures its text bounds against it as well, so a stored detail an older release bounded still decodes, and truncation charges a URL's characters past that reach, such as a balanced closing parenthesis, to the budget outside URLs, so an older release also decodes a detail this one wrote.
  - `redactDiagnosticText` and failure detail truncation no longer slow down quadratically on text with many URLs.
- The core skill no longer gives two conflicting starts for an input description. A description that records a limited use starts with "By design:", then states how many values the input takes, such as "By design: one postal code, used only to find nearby stores", so a host that checks the marker at the start of the description still finds it.
- A read build whose signed-out step entered a name, email or phone number the owner had confirmed, only to set the session's own state such as the store or location the read applies, was denied as out of authority: Guardian's execution policy called every such step a write, confirmed or not. Once confirmed, such a step is now part of the read. It still needs the owner's confirmation and is escalated without it, and a confirmed step that submits or sends something to a person or an organization, or creates an account or a lasting record on the site, stays a write. A recorded Guardian response keyed on the exact policy text needs recording again.
- A sign-in through code boxes that send the code themselves, with no submit for the host to click, could hang a fill call for as long as the browser's default timeout allows, or fail with the last box reported unfilled, when the page loaded its next screen while one of the host's looks for the page's own send read the boxes. A look's read of a box it had just found waited for that box to come back, and the check of the box typed last counted a box it could not read as empty. Now a step call's read of a control it already found waits at most 5 seconds, except in the fill of a date of birth, and in such a look a box the host cannot read fails the look, which the host takes again, so the fill reports that the page sent the code.
  - `isolatedLocatorPage` from `pomerado/testing/isolated-locator-page` now honors an isolated evaluation's `timeout`, as Patchright's own evaluation does.
- A sign-in whose code screen is one-character boxes, such as six boxes for a six-digit code, asked the owner for the code once per box and typed the whole code into each box. The site got a wrong code, and a request carrying the whole code never counted as sent. A screen's code is now asked once and typed one character into each box, without the spaces and hyphens it is often written with. A code that then leaves other than one character per box cannot be the screen's code, so nothing is typed and the sign-in stops for want of a value, as for any value the owner did not give. The sign-in counts the boxes' characters, joined in order, as the code a request carries, records and rules out after a refusal. A run's sign-in reads a code screen that came back after its page may have sent the code itself (`page`) as a refusal only once a request carried that code, so a page that only seemed to send it never gets a new code asked as if the site refused the last.
- A tool whose source imports the host runtime through a relative path, such as `../../runtime/index.js` or `../../browser/index.js` from `src/` as the workspace README says, could not be live tested: every `live_tests` run answered `source_unreadable` and ran nothing. The harness's digest of the tool's source followed that import out of the workspace, which refuses such a path, and the failure was dropped silently. The digest now follows imports only into `src/`, `explore/`, `test/` and `scratch/`, as the published bundle does, since the SDK is the host's and fixed within a job, and a digest the host cannot read is reported through `MintDependencies.reporting`. The write-repeat guard reads the same digest to refuse a copy of a write's step under another name. It was undefined for such a tool, so a repeat was matched by entrypoint alone; a copy is now refused, and a changed source still runs. A read build that published on its example alone, because its cases could not run, now runs them and sees their results.
- A local build's `check_signed_in_marker` read a page it loaded, the marker's `openPath` or the site's root and the other signed-in page, as lacking the marker when the page drew it more than about 2.5 seconds after its load, as a client-rendered page may. The host now checks each page it loaded again every half second until the page shows the marker, the check fails for another reason, or 10 seconds passed since its first check on that page. Only the first check loads the page; each later one reads it as it is. What counts as showing the marker is unchanged.
- A request with `maxResponseBytes` but without `buffered-response-v1` in `requires` failed `invalid_request` before sending, with no reason given. `maxResponseBytes` alone now sets the response limit; `buffered-response-v1` alone still selects the 8 MiB default.
- A publication review whose outcome Guardian kept refusing, `InvalidOutcome`, was recorded as a `PublicationDecision` with the recovery `retry`, and later question and task update reviews read that as trusted host evidence while the minter had been told to revise. It now has the recovery `correct_source`, or `ended` when it ended the attempt, and lists `InvalidOutcome` in `failedChecks`. Each review's diagnostics name such a failure `code: "InvalidOutcome"` instead of `ReviewUnavailable`. The first `review_invalid_outcome` answer no longer carries `retryable: true`, which tells the minter to submit the same call again; after live execution has closed, an execution's answer points to the retained receipt instead of a revised execution; and a host that becomes unavailable during the review ends the attempt with its own cause instead of no host failure. A host that matched diagnostics by `code: "ReviewUnavailable"` with `reviewFailure: "InvalidOutcome"` matches `code: "InvalidOutcome"` instead.
- A Guardian question or task update review was asked for the execution outcomes allow, deny or escalate before its own, so it could return `allow` where a question review accepts only `allow_business`, `authentication` or `reword`. The host then retried that review as an outage with backoff, from the same input. Each review's request now lists its own outcomes in `trusted_review.outcomes`, only execution, recovery and publication reviews get the execution outcome policy, and a refused outcome gets one correction in the same review before it fails as `InvalidOutcome`. The harness no longer treats `InvalidOutcome` as an outage: the first in an attempt comes back as `review_invalid_outcome` for the minter to revise or withdraw, and the second ends the attempt incomplete with no host failure, since reviews completing in between kept restarting the outage budget.
- A local build no longer publishes a tool that rests on a sign-in it never verified. A write build could sign in again in the middle of its session, write, and publish with no sign-in, so every later run started signed out. `finish_build` now refuses as `autofill_recipe_not_verified` when a step the publication rests on ran after a sign-in sent the login and before any check verified it, and the build has no verified sign-in to publish. A write rests on every act step of its session, and a read on the example or explore it publishes. A read is refused even when its example ran signed out.
- Guardian's source reads on the local host now find the SDK under `operation/`, where authored source imports it as `../../runtime/index.js` from `src/`. A read of `operation/runtime/index.js` or `operation/browser/form-controls.js` returns the trusted SDK file. It used to fail as unavailable. An authored file at the same path still comes first.
- The local host's SDK files for the minter's workspace and Guardian's source reads now include `runtime/files.js`, which `runtime/index.js` and `runtime/kernel-operation.js` import. A read of it used to fail as unavailable.
- A host can require a site name and summary on a site's first publication, even for a tool that never opens the site, such as one that only transforms its input. Guardian's publication review could read that naming as a claim that the tool uses the site and deny it as an unsupported claim, and the host would not publish without the naming. `publicationDecisionPolicy`, which the core publication policy includes, now says host-required site naming only identifies the site the tool is filed under and is no unsupported claim on its own. The tool's own name, description or a declared variant that promises site behavior the source lacks is still one. A host with its own publication policy gets this by including `publicationDecisionPolicy`.
- A browser's refusal of a DevTools command while the host typed a sign-in field, before the one call that carries the value, made the fill `uncertain`, and the minter read that the fields and the submit may have reached the site, so it did not sign in again. The host now skips a session whose document it cannot read or walk, such as a large third-party frame's, and refuses as `binding_unresolved` when a host's `bindingWorld` fails or the browser does not resolve the node, so such a failure refuses the field as typed nothing, `binding_not_found` when a skipped session held it. A failure of the call that carries the value stays `uncertain`. Its diagnostics now keep the error's `reason` and `method` beside its `code`, each only when no value of the step appears in it. The minter then reads that the field may hold its value and that the host never clicked the submit, and `lostTyping` from `pomerado/core/destinations/autofill-refusal` names such a report for a host. A lost answer of the submit's call keeps its message.
- A write that read back its confirmation and then failed for another reason, such as an unanswered question, a refused input or a rejected login, reported `possible_commit` false beside `write_status` `applied`. A caller that read only `possible_commit` could run it again and repeat the write. `possibleCommit` from `pomerado/core/runtime/run-outcome` now counts a write's verified effect, so such a failure carries `possible_commit` true. The local host's words for it say the website confirmed the action, so running the tool again would repeat it, and to read the site back before any retry; they never say to run it again. A read's verified effect still counts as no commit.
- A confirm question the minter asked beside a notice, such as approval of a site's terms with a note that nothing was submitted yet, was left out of the answers later Guardian reviews trust. A step that relied on the owner's yes was then escalated, and the owner was asked the same question again. `answersForReview` from `pomerado/core/guardian/question` now lists every answer except secrets and logins, whether or not the request carries a notice.
- The local host asked the owner a script's question again whenever a later step of the same build asked it, as when a step that failed before its commit ran again. A script's ask now reuses the owner's answer whenever the same question comes back in the build: however long ago the owner gave it, whether or not an earlier step entered a commit or may have, and as often as any step asks it, including the step that got it. The question must match by id, type, screened prompt, and screened options or follow-up, and the kept answer must still be valid for it. A code, secret or login question is always asked again, and so is a question after a task update or after the minter asked the owner a question with the same prompt. A newer script answer replaces the kept one. Guardian still reviews each ask, the script receives the reused answer in the same shape as a fresh one, and later reviews trust it as they trust a fresh answer.
- A write build whose script named a commit step with an underscore or a capital letter, such as `place_order` or `placeOrder`, could change the website during the build and then never publish. The live run entered the mark, but publication refused the declared name as `commit_marks_undeclared`, and the host had dropped the runner's whole commit report, so a renamed declaration was refused as `commit_marks_unentered`. `commitMarkPattern` from `pomerado/core/runtime/operation` now accepts any short identifier: a letter, then letters, digits, hyphens or underscores, still up to 48 characters. A name with a space or other punctuation, or a longer one, is still refused. A host that checks mark names with its own copy of the pattern should import this one.
- A sign-in step that splits a one-time code into one-character boxes, one field per character, was refused as it submitted when one of the code's digits stood alone in the form action's path or query, such as inside a flow ID, once the host had typed into the page earlier in the sign-in. The submission guard found each box's character as a code of its own, and missed the whole code in an action, since each digit adjoins the next. It now finds a step's code fields that each hold one character as one code, their values joined in field order, by the same rule as a code in one field. A code field that holds more than one character, and a password or other secret, is guarded on its own as before.
- Guardian could refuse a host sign-in step with a `code`, `recovery_code` or `private_answer` slot because no code or answer had been supplied yet, and tell the minter to ask for it first, which the auth skill forbids. The host asks the owner for that value only while the step runs, so the build could not go on. The execution policy's host sign-in rule now says the host fills such a slot only after Guardian allows the step, from a saved value or by asking the owner then, so Guardian allows the step without an earlier code or answer. A recorded Guardian response keyed on the exact policy text needs recording again.
- Guardian could still refuse a host sign-in step with a `code`, `recovery_code` or `private_answer` slot under its general rule that a live step never enters a value nobody supplied. Its review of the build's blocked report then told the minter again and again to ask for the code with `request_input`, which the auth skill forbids, so the build could not go on. The execution policy's general rule now exempts those slots, since the host fills them while the step runs, from a saved value or the owner's answer. The question review says the host asks for a host sign-in step's code while the step runs, so it is not requested with a separate question, and prefers telling the minter to send that step again. A recorded Guardian response keyed on the exact policy text needs recording again.
- A tool input that takes one of several object shapes named a field every shape refuses once per shape, so an unknown argument came back as the same issue repeated. `valueFreeIssues` from `pomerado/core/runtime/schema-issues`, which the MCP input schemas from `pomerado/core/mcp/schema` report through, now gives each distinct issue once, in the order the shapes report them.
- A publication finding whose path carried a fragment, such as a JSON pointer in `publication/definition.json#/outputSchema/properties/price`, or missed or added a leading directory, failed the whole decision as `InvalidDecision`. The host then ran the review again from the start, up to five times with backoff, with nothing telling Guardian what was wrong, so it repeated the same answer each time. `anchorQuotedFindings` from `pomerado/core/guardian/publication` now puts a quoted finding on the indexed file its path names exactly, an empty file's included, then on the file its part before a `#` names exactly, and otherwise on the one indexed file that shares the most trailing path segments with it, its file name at least, a current file before a historical one. A path that shares no file name, or that ties between files, still fails to decode.
  - A decision that does not decode gets one follow-up in the same review that names the decode error and, in a publication review, lists the indexed paths. If its answer does not decode either, the review fails `InvalidDecision` and is not reviewed again: the model already saw the error, so a fresh review from the same input mostly repeats the answer and costs a whole review. `reviewFollowUpRounds` is now four. `decodePublicationDecision`'s error names a finding path outside the index, or a reason its outcome and findings do not fit. An execution allow without an action label gets the same follow-up.
  - A review that could get no follow-up, a private host kind's or one whose host `Reviewer` never sends `turn.followUp`, is reviewed once more after `InvalidDecision`, in place of up to five times: a fresh sample may decode, as after a truncated output, but repeated ones mostly repeat the same answer. A host that counted on `guardianOutageRetry` to retry decode failures further gets one retry.
  - A host's own `decodePublication` must be pure: the review also runs it, with no source reads, to decide whether an output needs the follow-up. Only an `InvalidDecision` it returns at once gets the follow-up; another code, or a decode that needs asynchronous work, gets none.
- `chooseOption` and `fillDate` from `formControlsCode` pass their `timeout` to every read of the control and its list. A control or list that vanished while they read it, such as a dropdown the page drew again, made a read wait for the page's default timeout, 30 s in Playwright, however short the picker's own. Such a read now fails with Playwright's `TimeoutError` within the picker's timeout of when it started.
- A run's sign-in failed when the site asked for a one-time code the build's recorded sign-in never saw, and a read's could end on that code page as one that can't tell. After the recorded screens, when the account does not show and no code has gone out, the replay now looks once for a one-time-code field and its form's submit, on a recorded screen's origin or a configured sign-in origin off the site. It never looks while a field of the screen it last submitted still shows, such as a password screen shown again or a refused recovery code. It gets the code as a recorded code screen does, from a saved value or the same question to the owner, then submits it and checks the sign-in again. A field marked `autocomplete="one-time-code"` always counts, and a page with one counts only it. On a page with none, a text, number or phone input counts when its name or id holds otp, totp, 2fa or mfa, or holds code or verification on a short numeric box (`inputmode="numeric"`, or a number or phone input, with a `maxlength` of 4 to 8). Such a field never counts when its name, id or `autocomplete` holds password, email, username, search, zip, postal, post, phone, promo, coupon, discount, gift, voucher, referral, recovery, backup, captcha, security, confirmation, access, company, country, card, cvv, cvc, csc, pincode, redeem, area or year, holds pin as a word of its own, as in `pinCode` or `card_pin` but not `otpInput`, or its `autocomplete` starts with `tel` or `cc-`. A refused code is asked again only while the same screen shows. A fill that typed nothing leaves the sign-in to the usual check, and a code typed but never submitted fails the sign-in. A recipe whose check opens an account page usually skips the look, since that page opens first. Recipes and tools need no change.

## 0.3.0

This release lets the person answering a minting question use their own words on any choice, records each Guardian review attempt's timing, stops runs of a built integration from calling Guardian, and starts runs, live examples and a write session's first step from the site root. It changes answer and question shapes that 0.2.0 cannot read: upgrade every host that reads stored requests or answers before any that writes them.

### Breaking changes

- `ValidAnswer` values change type. A choice's value is `ChoiceValue` (`string | { other } | { option, note }`), and a multiple choice's is `MultiChoiceValue` (`readonly string[] | { options, other?, note? }`). Code that reads `.other` after a `typeof value !== "string"` check, or treats a multiple choice's value as an array, no longer compiles.
  - Migrate with `pickedOption(value)` for a choice's picked option, and an `"options" in value` check for a multiple choice.
- `ChoiceQuestion` gains `allowNote`, and `MultiChoiceQuestion` gains `allowOther` and `allowNote`. Every choice and multiple choice the minting agent asks carries `allowOther: true, allowNote: true`.
- `InvalidAnswer`'s `reason` adds `note_not_allowed`, for a note on a question without `allowNote`.
  - Migrate by giving any exhaustive check or list of reasons the new one.
- `AgentRequest`'s choices are `ProposedChoiceQuestion` and `ProposedMultiChoiceQuestion`, without `allowOther`. A `request_input` call that sets `allowOther` or `allowNote` is answered `question_invalid` and asked again without it.
  - Migrate any recorded model responses that set `allowOther`.
- `isReadOrWriteChoice` now accepts a read-or-write choice with `allowOther`. `AnsweredQuestion` gains optional `other` and `note`.
- Version 0.2.0 cannot read requests or answers in the new shapes: its strict decoders refuse the new question fields, and its `validateAnswer` and `validateKeptAnswers` refuse `{ option, note }` and `{ options, … }` as `malformed`. Upgrade every host that reads stored requests or answers before any that writes them, and do not roll back once they are stored.
- Guardian now reviews the read-or-write question the minter asks first, since it accepts the person's own words. A host whose question review refuses that question must allow it, or the first turn fails.
- New exports: `ChoiceValue`, `MultiChoiceValue`, `pickedOption`, `ProposedChoiceQuestion` and `ProposedMultiChoiceQuestion` from `pomerado/core/runtime/input-request`, and `withOwnWords` from `pomerado/core/mint/contracts`.
- Runs of a built integration, through `run` or a served integration MCP, no longer call Guardian and need no model key. Guardian still reviews minting. A run no longer checks its `intent`, `effect` or `authenticationOrigins`.
  - Migrate by checking a call's intent and effect in your host before it runs, if you relied on the run doing it.
- `pomerado run` no longer requires `--intent`, and it ignores `--intent` and `--effect`.
  - Migrate by dropping both flags. Neither limits what a run does.
- A run, through `run` or a served integration MCP, starts at the site root of its URL and no longer loads the URL's path. `pomerado run` and each served call start fresh, in a new browser context. A library caller's run closes the scope's other tabs and keeps its cookies and storage.
  - Migrate by having an operation that needs a deeper page navigate there itself, as its example already starts at the root.
- A live example, a live test and a write session's first `act` step start at the site root after other tabs close. A build that hasn't signed in clears the cookies and site storage exploration left. A signed-in build restores the session saved right after sign-in, or keeps its session when none was saved. Later `act` steps, explorations and inspections continue the current page. The first live step that isn't reset still loads the request's URL.
  - Migrate by writing example, test and first-step source that runs its flow from the root, as the authoring guide already asks.
- A sign-in check counts only after the build's own sign-in steps typed the login's identifier and a password or code, or the user completed an approval. A code the site sent for that sign-in, which the agent asked for, counts as its code once an explore made a completed `fill`, `type` or `pressSequentially` call with it on a page, frame, locator or keyboard, in a frame on the site or one of its `authenticationOrigins`. A frame with no address of its own, such as `about:srcdoc`, isn't on the site. Keys typed with nothing focused count only when every frame of the page is on the site or one of those origins, since they reach whichever of its documents has the focus. Source that only holds the code, or typing it anywhere else, counts nothing. Before that, the check returns `signedIn: false` with `failed: "credentials_not_submitted"` and leaves the build signed out. Every sign-in step drops the session saved after the last sign-in, a check included, and a check after a confirmed sign-in starts a new one, so checking again is refused.
  - Migrate by sending the sign-in screens' `signInStep` fields before the `signedIn` check, and checking once per sign-in.
- `MintDependencies.priorAttemptMayHaveChanged` is removed, with the notice it added to the agent's first input.
  - Migrate by giving the agent your own notice through `drainStartIncidents` if a restarted write build must read back before it writes again.
- In `pomerado/core/destinations/autofill-step`, `AutofillInspection.screen` adds a required `origin`, which `inspectAutofillStep` sets. A filled `AutofillStepReport`'s `submit` adds `"stayed_disabled"`: the fields were filled, but the submit stayed disabled through the wait, so the host never clicked it.
  - Migrate by setting `origin` on any inspection you build yourself, and by handling `"stayed_disabled"` in any exhaustive check on `submit`.
- `misplacedHandleRule` is no longer exported from `pomerado/core/mint/secret-handles`.
  - Migrate by calling `secretHandleRefusal`, which returns the whole refusal.
- A local build follows these read and write rules:
  - A read build may run its live example again. Its owner may approve turning it into a write build before it runs one.
  - `testInput` runs only on a read build's live test, as JSON text, at most twice per attempt. Any other use is refused before review.
  - `exampleInput` is a JSON object and runs only when the caller's input is empty: on a read build's example, or on a write build's act steps. The first act step that passes it and that Guardian allows fixes it for the session, whichever step that is. Act steps before it run the caller's empty input. Later act steps run it, and may repeat it unchanged or omit it. A different one is refused before review. Guardian reviews these act steps under a stricter effect: every value in that input, and any add-on or optional purchase the step chooses, must come from the request or an answered question, while values the page supplies follow the general policy. Publication decodes the composed contract against that input.
  - A write build refuses a live example or live test, and a live explore once its first act step ran. An unchanged act step right after one that may have changed the site is refused until another act step reads the result.
  - Once a write session started, an `authenticate` step without `signInStep` is refused, since it would run the agent's own source outside the session's act steps. A `signInStep` the host fills still runs.
  - `inspect` and `residual` are refused before review. A local build keeps no write maintenance, so it has no possible write to recover.
  - A secret handle is refused before Guardian reviews the step, instead of failing after review, when this attempt never issued it, when it sits in the source an example publishes, or when it is misplaced. A misplaced handle's refusal names its file and line. An offline step runs handle text as written.
  - A Guardian outage is retried for up to five minutes before the step reports the review as unavailable. A spent model quota ends the build with `model_quota_exhausted`.
- A local build's `finish_build` runs a publication review after its own checks. Guardian reads the files that would ship, the public definition and the example's output, or for a write each act step's source and the named step's output. A denial goes back to the minter with Guardian's reason and findings. Input feedback gets two rounds of fixes. If it remains after them, the build ends incomplete with Guardian's categories and rationale, and `pomerado mint` exits 1.
- A saved integration holds every file under `src/`, whatever its extension, the entrypoint, and the files under `explore/`, `test/` or `scratch/` that they import. Other files under those three folders are no longer saved. Every file under the four folders is saved, as before, when the workspace has a `package.json` or one of the folders holds `node_modules`, or when a file those imports reach could load one they don't name: through `fs`, `createRequire`, a `#` import, a computed import, its CommonJS wrapper's arguments or Playwright's internal `playwright/lib/` modules, as a WebAssembly module or native addon, or because it doesn't parse as JavaScript, such as an extensionless file that isn't.
  - Paths and these names match in any letter case and Unicode normalization, as macOS loads files. An import of `../Explore/Look.mjs` saves `explore/look.mjs`, and a `PACKAGE.JSON` or `Node_Modules` counts.
  - A property or TypeScript type member named `arguments`, such as a tool call's `call.arguments`, is not the wrapper's arguments. The property still counts when read straight off a call's result, as in `frame.getFunction().arguments`.
- When a host's `specialize` returns no `policy` for a publication review, the OpenAI reviewer gives that review the core publication policy after the outcome policy, its file index as `trusted_publication` before `trusted_execution_environment`, and 32 turns unless `specialize` sets `maxTurns`. A reviewer with no `specialize`, as the local host uses, gets all three.
  - A host that returns its own `policy` from `specialize` for a publication review needs no change: it keeps exactly its policy, input and turn limit.
- A harness with no `inputFeedbackFallback` tells the minter that the build ends unpublished once input feedback outlasts its two rounds, then ends the build incomplete with the last review's categories and rationale. A harness with a fallback is unchanged.
- A sign-in step can record a security question's answer field with the new `private_answer` slot, on every host. `SignInStep` and `ExecutionRequest` in `pomerado/core/mint/contracts` take it, so the execute tool offers it to every host's minter. `SecretSlots` in `pomerado/core/destinations/autofill-contracts` adds it, and so do `ExtraSecretSlot` and `AutofillSlot` in `pomerado/core/destinations/autofill-step`. A `private_answer` field may name the observed question it answers (`questionSelector`), and only that slot may. `RejectedMarker` does not accept it.
  - Migrate by handling `"private_answer"` in any exhaustive check on a slot. A host that fills sign-in steps itself must supply each `private_answer` field's value, the owner's answer to the question the page shows, or fail that step clearly.
- `checkAutofillSignedIn` in `pomerado/core/destinations/autofill-step` returns `failed: "challenge_form_visible"`, which `AutofillSignedInCheck`'s `failed` adds, while a recorded challenge field still shows. It takes an optional `challengeScreens`, the current sign-in's screens, which are `screens` when left out, and an optional `authenticationOrigins`, the configured sign-in origins, which are none when left out. Each field of `AutofillScreens` takes an optional `slot` and `identity`.
  - Migrate by handling `"challenge_form_visible"` in any exhaustive check on `failed`. To have the check refuse a challenge that still shows, pass each field's `slot` and, from its inspection's screen field, its `identity` (`label`, `ariaLabel`, `placeholder`, `type`, `autocomplete`, `name` and `id`). A field with no `identity` counts for nothing.
- `SignedInPage` in `pomerado/core/destinations/autofill-page-code`, the answer of `autofillSignedInCode`, requires `challengeFormVisible`.
  - Migrate a host that decodes its own page code's answer with `SignedInPage` by returning `challengeFormVisible`, `false` when it checks no challenge.
- `InsertionRefusal` in `pomerado/core/destinations/credential-keyboard` adds `"question_changed"`: a private answer's question no longer reads as the host inspected it. The fill reports it under the `change` check, and `HostRefusal` in `pomerado/core/destinations/autofill-refusal` takes an optional `cause`, `"question_changed"`, for it.
  - Migrate by handling `"question_changed"` in any exhaustive check on a native insertion's answer.
- A local build asks for the website login once, as one `credential` question for a username and password that is never saved, when its first sign-in screen needs it. It no longer asks a secret question for each field. After the site rejects the login, the correction is asked the same way, once. Codes, recovery codes, dates of birth, ZIP codes and identifiers the login lacks are asked on their own, in the site's words, and a security answer each time a screen shows its question. An approval is a yes-or-no confirmation.
- A local build counts a sign-in value as sent only once a request the page sent carried it. While a sign-in is open, the local browser reports each request the page sends to the host, with a body up to 64 KiB, which the host holds in memory and only matches against the values it filled. It reports nothing while no sign-in is open. A signed-in check verifies the sign-in only when a request carried the login's identifier and the sign-in proved it: a request carried a password or code, the owner completed an approval, or an exploration typed a sign-in code.
  - A screen that asks for a password before any identifier screen, while the build holds no login, is refused with `login_identifier_unobserved`. It asks and types nothing.
  - A password or code is filled twice at most in one sign-in, and any other value once. A selector, page address or signed-in check that names the account's identity is refused before anything is typed.
  - A rejected value is accepted only when this sign-in sent it. A rejected code gets two fresh ones. A rejected login gets one correction, and the build ends with `credentials_rejected` when the site rejects it again or the correction repeats it.
  - A screen's result holds its report as `step`, with a `nextStep`.
- A local build publishes its verified sign-in with the integration, with no value in it. `auth-fill.json`, beside `pomerado.json`, holds the sign-in recipe: each screen's page, field selectors and slots, submit, and the signed-in check. It is version 3 only when a security answer names its question, and version 1 or 2 otherwise. `pomerado.json` names it as `signIn: { recipe: "auth-fill.json", entryUrl }`, where the entry is the minter's `loginUrl`, else the first screen's address, without any credentials or fragment it held. `MintArtifact` and `Artifact` take the same optional `signIn`.
  - A login URL that holds a value the build was given, such as the login's email in its query, is not published. `finish_build` answers `login_url_contains_credential` for the login URL and never shows the value, and the build can sign in again from a URL without it. A recipe that holds such a value is not published either.
  - `writeArtifact` writes `auth-fill.json` with each screen's keys in one fixed order, indented two spaces, with no final newline, so the same recipe gives the same bytes.
  - `auth-fill.json` is reserved, like `pomerado.json`: an artifact's source may not use the name.
  - `readArtifact` refuses an artifact whose recipe it cannot read or whose version it does not know. An artifact with no `signIn` reads as before.
- A run of an artifact with a published sign-in signs in with its recipe before the operation runs.
  - It first replays the recipe without values, and asks nothing when the session already shows the signed-in check. Otherwise it asks for the login once, as one `credential` question that is never saved, and for each code, date of birth, ZIP code or missing identifier a screen needs, in the site's words. A security answer is asked on every run, from the question its screen shows then. Values stay in memory for the run.
  - A rejected username or password is asked for again at most twice. A correction that repeats a value the site rejected is never sent, and counts as one of the two. A rejected code gets two fresh ones at most, as in a build.
  - The entry page must be on the site or a configured sign-in origin, and each screen on the origin its build recorded.
  - A run that can't sign in fails with `SignInRunFailed` before its operation runs. Its `code` is `CredentialsRejected`, `NeedsInput`, `RecipeFailed` or `MissingRecipe`, and its `reason` names a field or step, never a value. A security question that changed before its answer was typed is `NeedsInput` with `question_changed`, and an entry page that didn't load is `RecipeFailed` with `entry_page_unavailable`. A browser failure during the sign-in fails the run as it would during the operation.
  - An MCP call reports it as `Sign-in failed (code)` with what to do next, and without the warning that a website action may have taken effect, since the operation never ran.
  - `readArtifact` fails with `SignInRunFailed` and code `MissingRecipe` for a recipe that is missing, unreadable or of a version the host doesn't know, with `reason` `missing`, `invalid` or `unknown_version`.
  - An artifact with no `signIn`, as 0.2.0 wrote it, runs as before.
  - `pomerado` exports `SignInRunFailed`.
  - Migrate a library caller that runs a signed-in artifact by answering the login question through its `ask`, and by handling `SignInRunFailed`.
- `makeLiveAuthentication` is no longer exported from `pomerado`. `createPomerado` signs in itself.
- `HostRefusal.cause` in `pomerado/core/destinations/autofill-refusal` is now any `InsertionRefusal` from `pomerado/core/destinations/credential-keyboard`, not only `"question_changed"`. `typingRefusal` sets it to the finite cause of a native insertion that inserted nothing, under the `typing_refused` check. `sameHostRefusal` compares it, so refusals with different causes no longer count as one repeated refusal. The minter's sign-in notice explains each group of causes with its own next step: the focus left the field, the field or page was replaced or navigated, the bound field could not be found, or the browser rejected the inserted text. No notice names a binding, a selector or a value.
  - Migrate by handling every `InsertionRefusal` in any exhaustive check on `HostRefusal.cause`.

The package now holds the code the local host runs, the hook interfaces another host implements, and the signed-in marker checks behind `MintDependencies.checkSignedInMarker`. Local use through `pomerado`, `pomerado/mcp` and the CLI needs no change for the following.

- `makeOpenAIReviewer` from `pomerado/core/guardian/openai` takes all three arguments, and its options need `executionEnvironment`. That option is a `GuardianExecutionEnvironment` object instead of `"hosted"` or `"native"`, and nothing defaults it. The `"hosted"` text is gone.
  - Migrate from `"native"` by passing `nativeExecutionEnvironment`, which gives the same policy text. Import it and the `GuardianExecutionEnvironment` type from `pomerado/core/guardian/openai`.
  - Migrate from `"hosted"` by passing your own `GuardianExecutionEnvironment`. Its `name` reaches the model as `trusted_execution_environment`.
- `loadAuthoringSkills` and `loadWorkspaceGuide` take an optional `render` function in place of the `"standalone"` or `"hosted"` mode, and `AuthoringMode` is gone. The default still renders each section's standalone text.
  - Migrate from `"hosted"` by passing a render that returns your composed text and refuses any section marker left in it.
- `makeCredentialKeyboard` takes an optional `bindingWorld` function in place of `utilityWorldName`. The function returns the execution context to resolve the field in. Without it, the field resolves in the page's main world, as before.
  - Migrate by creating your isolated world in that function and returning its context ID.
- Modules and exports nothing in the package used are removed.
  - `pomerado/core/browser/promise`, with `browserPromise`. The local host never ran it.
  - `pomerado/core/destinations/cdp-contracts`, with `kernelPlaywrightUtilityWorld` and its DevTools message schemas.
  - `pomerado/core/privacy/common-values`, with `isCommonSecretValue`, `isDiscoveredWebFlag` and `isOpaqueCredentialValue`. Nothing in the package called them once the unused `pomerado/core/privacy/secret-keys` exports went.
  - `DialogDecision`, `DialogScope`, `PendingDialog`, `DialogFacts`, `ResolvedDialog` and `KnownDialog` from `pomerado/core/browser/dialogs/contracts`. `ExpectedConfirm` stays.
  - `finalHostFailures`, `BuildCallerResult` and `MintDependencies.prepareWriteUpgrade` from `pomerado/core/mint/contracts`
  - `savedProfileSetAsideNotice` and `signInPendingNotice` from `pomerado/core/mint/sign-in-failure`
  - `mintSourceSyntaxFailure` from `pomerado/core/mint/operation-source`
  - `boundaryError` from `pomerado/core/execution/boundary`
  - `withCauseEntry`, `failureDetailFiniteMetadata` and `failureFiniteNames` from `pomerado/core/runtime/failure-detail`
  - `isSecretOrLooseKey`, `isCredentialContextKey`, `isCredentialName`, `credentialFieldPropagation`, `cookiePropagation`, `isSessionTokenField` and `sessionTokenEntity` from `pomerado/core/privacy/secret-keys`, which keeps `isSecretKey`
  - `refusalEvidence` and `callFailure` from `pomerado/core/destinations/autofill-refusal`. A refused step's evidence is still its report's `failureDetail.context`.
  - `executeKernelOperation` and `offlineKernel` from `pomerado/core/runtime/kernel-operation`. The local runner runs a script with `runKernelScript`, which stays. To run one as `executeKernelOperation` did, wrap `runKernelScript` in `decodeKernelOperationInput` and `validateKernelOperationOutput`, now exported from `pomerado/core/runtime/kernel-operation-validation`.
  - `failureCause` from `pomerado/core/runtime/errors`
  - `asksAsDeclared` from `pomerado/core/runtime/script-input`
  - `autofillMarkerVisible` from `pomerado/core/destinations/autofill-page`, which keeps `openAutofillLogin`. The page code it built on, `autofillPageCode`, is now exported from `pomerado/core/destinations/autofill-page-code`.
  - `credentialRequestMessage`, `holdsSecrets`, `inputWindowMs`, `keepAnswerRecovery` and `validateKeptAnswers` from `pomerado/core/runtime/input-request`
  - `loginFieldsOfRecipe`, `publicLoginFields`, `revisionLoginFields`, `unusedRunLoginField`, `inlineLoginFields`, `InlineLoginField` and `LoginFieldsUsed` from `pomerado/core/destinations/login-fields`, which keeps `LoginField`, `LoginFields` and `SignInMethods`
  - `isHostIncident` from `pomerado/core/mint/incident-contracts`
  - `SignInRecoveryEvent` from `pomerado/core/execution/sign-in-diagnostics`
  - `BrowserMode` from `pomerado/core/runtime/provider-metadata`
  - `sameRegistrableDomain` from `pomerado/core/runtime/same-site`
  - Migrate by keeping your own copy of what you use in your host.
- The named authoring sections a host fills with its own text changed. Guidance that holds on every host is now shared text, which every host reads, and the sections keep only what one host says about its own facilities.
  - Removed, because their text is now shared: `core.secret-answers`, `agents.retries`, `caller-input.published-input`, `caller-input.ask-limits`, `caller-input.during-mint`, `forms.role-names`, `forms.selection-intent`, `pagination.continuation`, `writes.frontmatter`, `writes.task` and `writes.compose`.
  - Added: `core.example-input`, `core.example-readers`, `core.challenge-reference`, `core.testing-reference`, `core.sign-in-request`, `core.login-source`, `agents.file-lengths`, `agents.large-content`, `agents.login-evidence`, `agents.login-credentials` and `agents.login-selection`.
  - Kept, with the shared text around them now outside: `core.operation-shape`, `core.execute-calls`, `core.schema-coverage`, `core.site-origin`, `core.tools-and-files`, `core.references`, `core.login-markup`, `core.credentials`, `agents.role`, `agents.progressive-reads`, `agents.authentication`, `agents.report-blocked`, `agents.completion`, `forms.step-rules`, `pagination.no-recreated-writes`, `writes.finish`, `auth.slow-screens` and `auth.next-screen`. The shared completion rules now come before `agents.completion`.
  - Migrate by giving each added section your host's own text, or none, and by removing from your text for each kept section what the package now shares.
- The package ships a `publication` skill at `publication/SKILL.md`, with named sections for what one host says about its own publication: `publication.site-heading`, `publication.metadata-readers`, `publication.integration-name`, `publication.unique-name`, `publication.description-reader`, `publication.site-naming`, `publication.saved-http`, `publication.login-url`, `publication.http`, `publication.recorded-requests`, `publication.host-owned`, `publication.host-bundle-files`, `publication.saved-files`, `publication.host-checks`, `publication.confirm-steps`, `publication.route-evidence`, `publication.review-host`, `publication.recorded-sends`, `publication.site-claims`, `publication.input-feedback-end`, `publication.http-rejections`, `publication.token-codes`, `publication.token-meaning`, `publication.token-source`, `publication.token-retest`, `publication.confirm-action`, `publication.host-rejections`, `publication.protected-result` and `publication.screening-rejections`.
  - The workspace `AGENTS.md` sections `agents.publication-heading` and `agents.publication-skill` are removed, because their text is now shared. `agents.http-version` and `agents.write-captures` are added, and `agents.publication-evidence` is kept, with the shared text around them now outside.
  - Migrate by giving each publication section your host's own text, or none, by removing from your `agents.publication-evidence` text what the package now shares, and by dropping any skill of your own at `publication/SKILL.md`, the package's path.
- The core skill adds the named section `core.stale-session`, right after "saved right after sign-in instead". It holds the rest of that sentence, on what a stale saved session does after a live step's reset, and the next sentence through "the flow from its input,", so a host's text can wrap those lines its own way. Its standalone text is the local wording, unchanged: a stale session shows up as a login wall that a new sign-in fixes. A host whose sessions behave otherwise can say so instead.
  - Migrate by giving `core.stale-session` your host's own text. To keep the current wording, use the section's standalone text.

### Other changes

- Guardian diagnostics record each review attempt's interval, failed source-read duration, session permit wait, and scheduled retry backoff. Follow-up rounds for a skipped entrypoint read stay inside one attempt, and its closing record counts them. A private host kind, whose transcript is not kept, can forward its finite model and tool timing through `observeModelTrace`.
- `pomerado/runtime` exports `CalendarDate`, a date-only `YYYY-MM-DD` schema that refuses a date that does not exist, such as `2026-02-30`, with the calendar check `fillDate` already made. Its JSON Schema is `format: "date"`. It sets no date range. The forms skill and the date examples use it, and say that a range's order, a past date or a booking limit is the tool's own `InvalidInput` check.
- A generated integration's MCP tool names the failing input path and rule when arguments do not match its schema, and a failed job reports the tool's own `InvalidInput` message.
- The person answering a minting question may always answer a choice or multiple choice in their own words: their own text instead of an option, or a note beside the options they pick. The host marks every choice and multiple choice the minting agent asks with `allowOther` and the new `allowNote`, and Guardian now reviews the effect question too, since its answer may be free text. An answer in the person's own words to a read-or-write question approves no write: the effect question is asked again, and a write upgrade leaves the build read-only without settling it.
  - A choice answer may now be `{ "option": id, "note": text }`, and a multiple choice answer `{ "options": [ids], "other": text, "note": text }` (`other` and `note` optional). `other` counts toward `minSelections` but not `maxSelections`, and unlike a choice's own text it is never turned into a pick.
  - Answered questions in Guardian reviews carry the person's `other` and `note`. A note counts as the person's own words for `ownerNamedOrigins`, unless it only repeats an offered option.
- Integrations generated by earlier versions still have README text that asks for `OPENAI_API_KEY`. They no longer need it.
- A failed run that has no more specific message now reads "Operation failed. Check the local browser and integration configuration." Minting keeps its message.
- `pomerado/core/runtime/start-state` holds the start-state decision (`startStateFor`, `shouldSaveSession`, `isFirstWriteStep`), the per-build `makeStartTracker`, and the page reset: `startPage` with its required `StartPageHooks`, `localStartHooks`, and the `resetPageCode`, `stopLoadingCode` and `saveSessionCode` browser code.
- A signed-in build's saved session must fit the page-code worker's 1 MiB result cap. A larger one fails the save and every later live step other than a sign-in step, and a new sign-in hits the same cap.
- Every merge to `main` publishes a canary, `X.Y.Z-canary.N`, under the `canary` dist-tag: `npm install pomerado@canary`. `latest` moves to the canary that Pomerado's hosted service promotes to production, so `npm install pomerado` gets the build production runs. The range it saves, such as `^0.2.1-canary.57`, also matches later canaries, so install with `--save-exact` or keep a lockfile. See [Releasing](docs/RELEASING.md).
- A host sign-in step fills a form whose submit is disabled, `aria-disabled` or in a disabled fieldset until the fields hold input. The host waits up to 5 seconds for the page to enable the submit, then clicks it, and never clicks it while it is disabled. It reads whether the submit is disabled the way Playwright's click does, which page scripts can't change. An `aria-disabled` wrapper keeps a submit waiting only when the submit itself has an ARIA role, as Playwright judges it. A page that changes the form's controls three times during the wait is refused. A submit in an `inert` region is still refused before anything is typed.
- Guardian's review of a host sign-in step shows the origin of the frame the step's controls are in, as the browser reports it, and no longer requires the submit to be enabled. The auth skill likewise lets the minter record a submit the page has not enabled yet.
- A write session step can carry `withheldConfirmation` when it read the site's confirmation but the host did not accept its result. It leaves the session open, so a later step that only reads the confirmation back confirms it. Publishing against the withheld step returns `read_back_required` unless `finish_build` passes `readBackUnavailable`, the reason no step can read the confirmation back. The host's `publish` receives that reason, screened. The step's receipt shows `withheldConfirmation` with an instruction never to repeat the write, and it keeps the attempt open for publication when live execution ends. A host that sets it must settle the step's entered commit marks for later act steps.
- Guardian's execution review treats the site's own page traffic as the website's behavior. Scripts, trackers and beacons the page loads, with whatever caller input the site gives them, are never a reason to deny or escalate, and the off-site rule judges only what the source itself sends. An anonymous recent-search or search-state save the page fires on a read's search is part of that read. A recording gap in a step result no longer stops live probes, and it still leaves that execution possibly dispatched.
- Guardian's question review no longer reads host sign-in rules, including an earlier review's text, as the owner forbidding sign-in. Only trusted intent or an owner's answer can. It no longer rewords a sign-in method or account question because sign-in is not yet proven required.
- The minter skills have it read back each value before a write's commit, on every branch of the composed script, and fail before the commit on a mismatch. They also accept a page's recent-search save as normal, and look everywhere the site keeps a value before calling it unavailable.
- `makeGuardian` decodes a publication decision with the package's own decoder, which checks each finding against the review's file index, when the host passes no `decodePublication`, instead of failing it as an invalid decision. A host's own `decodePublication` still decodes when given.
- `savedOperationFiles` and `runnableOperationFiles` from `pomerado/core/mint/operation-source` give the files a local build saves and the saved files its operation could run. `operationSourceFiles` is unchanged.
- A local `finish_build` refuses to publish when a saved file the operation could run holds a secret handle, whatever its extension: a file it reaches through its imports, or any saved file when Node could load one those imports don't name. Node could when one of the four folders holds `node_modules`, a saved `package.json` outside `src/` declares `exports` or doesn't parse, or a reached file could load another as the save rule describes. A `package.json` under `src/`, whose `exports` can only map files under `src/`, or one without `exports`, such as `{}`, still saves every file under the four folders but doesn't widen the check. `holdsSecretHandle`, the check it uses, is exported from `pomerado/core/mint/secret-handles`; `publishedHandlePath` is unchanged.
- `reviewDenied` from `pomerado/core/mint/review-context` keeps a decision's `reason` and `findings` on the failure's `review` when the decision has them.
- `pomerado/core/mint/step-checks` exports `sourceDigest`, the sha256 digest of a set of source files in any order.
- `inputFeedbackInstruction`'s `privateFallback` is optional. Leaving it out, for a build with no fallback, ends the instruction with the build ending unpublished. `unresolvedInputFeedbackSummary(cause?, review?)` reports a review's categories and rationale when given one and no cause.
- A contract run's result carries the operation's declared questions. A harness checkpoint of a build with no fallback keeps the last input-feedback review's categories and rationale.
- Each Guardian review of a local build carries that step's own context: the effects its kind of step may have, the files its entrypoint imports, the last six step results, the input schema of the latest example or contract run, the page the browser last showed with a redacted readable capture, a command's sandbox limits, steps still running and whether the browser has opened yet. A step that starts on a reset page, such as a live example, gets no page, nor does a question it asks while it runs. A question review gets no allowed effects. A read step's effects keep the limits the request states, such as a date range or filter, and tell Guardian that context the request gives, such as today's date, is no filter unless the request applies it.
- The minter and Guardian read today's date and time in UTC from the build's observations. Guardian's review of a contract run says what that run does.
- `pomerado/core/mint/review-context` and `pomerado/core/mint/step-checks` export these rules for other hosts, and `secretHandleRefusal` joins `pomerado/core/mint/secret-handles`.
- Guardian's review of a contract run carries the input that run decodes: the example's input, or the write session's.
- A page with more than 10,000 elements is not captured for Guardian, which reads that the page was too large. A page that does not answer within the capture's time, as when its scripts keep it busy, is not captured either, and the browser keeps running. A capture is cut to 256 KiB in the browser, before it reaches the host.
- A caller's secret is also redacted in the forms a page or URL shows it: trimmed, with its whitespace collapsed, with each `'` doubled or its control characters escaped as a page snapshot writes them, and percent-encoded as `encodeURIComponent` or a form writes it, or as Chromium writes it into a URL's query, path or fragment, in either hex case. A capture cut at 256 KiB keeps no prefix of a secret the cut split. A secret that cannot be percent-encoded no longer fails its registration.
- A sign-in screen can record a security-question answer field with `slot: "private_answer"` and, when the question has one visible match in that field's frame, the question's `questionSelector`. The local host asks for each answer on every step that has one, from the question it reads on the page or else the field's label, and never reuses or saves an answer. It reads the question again before it focuses the field and just before it types, and refuses the field if the question changed, and the minting agent hears that the question changed. It cuts a long question to fit the prompt, and says in the prompt when it could not read the recorded question. No answer reaches the minting agent, Guardian, generated code or any saved file. A private answer has no rejection marker and no automatic correction. Guardian's execution policy, for every execution environment, allows `private_answer` only on a security question's answer field, and the auth skill describes the slot for every host.
- The signed-in check refuses a recorded challenge that still asks. A code, recovery-code or private-answer field the current sign-in recorded counts while it still shows and takes typing, only on the same control the host inspected: the same label, `aria-label` and placeholder name it, with the same type, autocomplete, name and id where recorded. It counts in the page or a frame on the site or a configured sign-in origin, when every frame above it shows. Another control the recorded selector matches, such as a gift-card box or a redeem box with the same label and another name or id, does not count, and neither does a read-only or disabled control, an unconfigured off-site frame, an earlier sign-in's field, or a control or frame the host cannot read within 1.5 seconds, such as one that detaches during the check. A challenge the site renders again under other naming counts as a different control and does not fail the check: one with its error text inside the label, or one whose id or name the page generates on each render, such as `:r3:` or `mat-input-3`. The check fails open there, and the signed-in marker still has to show. The check reads only recorded selectors, never field names or routes. The local host records each field's identity, and ends a sign-in at a check that shows the site signed in.
- `autofillSignedInCode` in `pomerado/core/destinations/autofill-page-code` takes two optional arguments after `popups`: `challengeFields`, each a recorded selector with the `ControlIdentity` the host inspected, and `authenticationOrigins`. Left out, the code checks no challenge and answers `challengeFormVisible: false`, so a caller's existing arguments keep their meaning. The same module exports the `ControlIdentity` type, and its `autofillStepCode` reads each field's optional `slot` and `questionSelector`.
- `pomerado/core/destinations/autofill-locate-code` exports `questionTextCode`, the page code that reads a question's visible text for inspection and for the insertion guard.
- In `pomerado/core/destinations/autofill-step`, `AutofillField` and `AutofillStepRequest`'s fields take an optional `questionSelector`, `AutofillInspection`'s screen fields an optional `questionText` and `questionUnread`, and `LocatedError` an optional `question: "changed"`.
- The local host refuses source a Guardian review reads, and source a build publishes, for a caller's secret under eight characters (`makeRunSecrets`), such as a short security answer or a six-digit code, only where it stands as a whole token, as the submission guard finds a code: an all-digit one where no digit adjoins it, any other where no letter or digit does. A short answer such as "red" no longer refuses source holding "required". A longer secret is refused anywhere, as before. Redaction still masks every secret wherever it appears.
- The core authoring skill has a write build whose caller sent an empty input pass the request's values as `exampleInput` on each act step that needs them, as a read does on its example. An optional input plus a declared question is only for a value the request leaves open, and a required field is never made optional with nothing that asks.
- The minter gets a `publication` skill, and its instructions gain a Publication section that sends it there before its first `finish_build`. The skill says what a local publication checks, which private values never go into published files and what each refusal means, including that input feedback still open after its two rounds ends the build unpublished. The core skill and the workspace README list it among the skills to read.
- The minter reads guidance in places its authoring showed empty: the operation's shape and its execute calls, input and output schema rules, the site origin and page readiness, the tools and references, how to finish, sign-in markup and credentials, its role, loading large content in parts, four sign-in stages, review retries, ending blocked, completion, published inputs and question limits, questions during a mint, accessible names, selection intent, multi-step forms, pagination continuation, the writes skill's header, task, composition and finish, slow sign-in screens and the next sign-in screen. The secret answer rules now list every place a handle may go and every refusal, as the host enforces them.
- Guardian's question review counts only the host's own masks and `{{secret.<id>}}` handles as stand-ins for a supplied value. A placeholder written into the intent text in place of a value, such as `"[redacted value]"`, supplies nothing, so a question asking for that value is not redundant. The caller-input skill says the same.
- Guardian's execution review applies its `intent_derived` input rule to a write's act step as well as a read's example.
- A write session's `exampleInput` may come from any act step, as the core authoring skill tells the minter to pass it on each act step that needs it. The first act step that passes it fixes the session's input, even after earlier act steps ran on the caller's empty input. Later act steps repeat it unchanged or omit it, a different one is still refused before review, and publication decodes the composed contract against that input. Before, an act step that passed it after one that did not was refused.
- An operation can ask the host to restore a signed-in session that a full page load lost, as on a site that keeps its session only in page memory. A script calls `await ensureSignedIn()` after a full page load mid-script. It returns `{ signedInAgain }`, and a script that gets `true` opens its page again. The host checks the page and signs in again only when it is signed out. The operation's deadline pauses meanwhile. The auth skill says when to call it, and never to call it between a write's commit and its read-back.
  - A host provides it through the optional `signIn` hook on the browser it passes `runKernelScript`, and binds it only for an operation that runs signed in. The runtime calls it once before the operation's code runs. With no hook, or on an offline run, `ensureSignedIn` returns `{ signedInAgain: false }` and calls nothing.
  - When the host cannot sign in again, the call throws `OperationFailure` with the new `sessionLoss: "session_not_kept"`. A credential the site rejected still throws `CredentialsRejected`.
  - `pomerado/core/mint/contracts` adds `MintFailure.sessionLoss` (`SessionLoss`).
  - A build ended by `sessionLoss`, with every sign-in verified, now says the site accepted the login each time but the signed-in session did not survive the page load. It no longer reports a failed or spent sign-in. The agent is told to report it, the sign-in diagnostic records the cause, and the result stays `sign_in_unavailable`.
- The minter can test a signed-in marker against the signed-out page before it sends it, with the new `check_signed_in_marker` tool (`{ selector, urlPath?, openPath? }`). A host implements it with the optional `MintDependencies.checkSignedInMarker`, which returns `SignedInMarkerCheck`: whether the signed-out snapshot shows the marker (`signedOutSnapshot`: `absent`, `matches` or `unchecked`), and whether the live page shows it now, after a fresh load and on a second signed-in page. The tool is offered on every turn but the first question, and reports the check unavailable on a host without it. A host may describe it through `HostToolDescriptions.checkSignedInMarker`.
  - `pomerado/core/destinations/signed-in-marker` holds `evaluateSignedInMarker` and `matchSignedOutSnapshots`, which match a marker against a saved, masked signed-out document, and the validators a host runs before it accepts a marker: `signedOutMatchRefusal` (`marker_matches_signed_out_page`), `loginPathRefusal` (`marker_is_login_path`, for a path alone that is the login page's), `generatedClassWarning` (`selector_relies_on_generated_classes`) and `validateSignedInMarker`, which runs them all with the live checks. The match is approximate: CSS, text and role selectors on the static main document (no shadow roots or frames), with visibility estimated without stylesheets or layout, so an element only a stylesheet hides counts as visible. A role it doesn't know, or a role name it can't compute, such as a form field's label, leaves the page `unchecked`, and the tool then reports `passed_unchecked` rather than a plain pass.
  - The auth skill's standalone text says where the marker is checked (after resets, at each operation's start, after page loads mid-script and wherever a failure lands), so it picks a site-wide element only a signed-in user sees, tests it with the tool, prefers stable attributes and never sends a path alone on a single-page app. Account chrome is fine as that marker once the signed-out page lacks it; the evidence that the sign-in reached the caller's workflow is unchanged.
- While the host restores an operation's sign-in, through `ensureSignedIn()` or the runtime's own call before the script runs, every other browser call the operation makes waits until the host's `signIn` hook returns: execute calls, `waitPastChallenge`, `rejectedSignIn` and `decideDialog`, including ones a timer or an un-awaited promise starts. They then go in the order they were made, and a held call's own timeout starts only when it is sent. A failed sign-in releases them too, and the `ensureSignedIn` caller gets the failure. A second `ensureSignedIn()` while one is under way joins it instead of signing in again. This keeps a script from acting on the page mid sign-in; it is not a security boundary.
- A local build remembers, for its whole session, whether the host typed a sign-in value into the page. Once it has, every later sign-in screen, in the same build or a later build in that session, is judged as typed into. Its submit guard trusts a typed secret in a form destination only inside the site's own or a configured sign-in origin, never in a path or query the page chose, and a refusal names only origins judged before the typing. Before, each screen was judged as if nothing had been typed.
- A local build's minter can test a signed-in marker with `check_signed_in_marker`, which reported the check unavailable before.
  - The local host compares the marker with the pages it saw signed out. These are the page of the build's first sign-in screen, kept once the host found the screen's fields and just before it types, and each page a reset cleared of cookies and site storage. Before it reads a page, it waits for the load, then a quiet network, then 1.5 seconds without a change to the document. A fast page is read then, about 2 seconds after its load, and a client-rendered page that renders within about 1.5 seconds of its network going quiet is read rendered. The wait stops at 3 seconds in all, and a page whose load, network or document is still busy then is read as it is. It keeps only a page on the site's origin that shows text, a form control or an image. Once the host typed a sign-in value in the session, in any build, it keeps no sign-in screen's page. The signed-out pages stay in memory, and are never written or shown to a model.
  - A signed-out page the host didn't see settle counts only where it shows the marker, or where the match can't tell. That is a page still busy when the wait stops, or one that showed nothing when its document went quiet and showed something later. It may show more after the host read it, so it never shows a marker absent. With no other signed-out page, the check's signed-out result is `unchecked`, and a marker that passes the live checks reports `passed_unchecked`. The host doesn't see what a page renders after it read it: a page that goes 1.5 seconds without a change, then renders its signed-out header, is read without that header, and shows a marker in it absent.
  - It then checks the live page as it is, the marker's `openPath` or the site's root loaded again, and the newest other page the build explored once its current sign-in sent the login. A later sign-in screen, rejected value, approval or typed code forgets the pages explored before it. The other page is loaded only when the live page shows the marker, and is never that page or the one loaded fresh.
  - The loads move the tab. The host opens the agent's address again only when that page showed the marker and isn't the direct answer to a form. Otherwise the tab stays where the loads left it. An address that doesn't open again fails the check as unavailable.
  - Once the write session started, the check loads no page and fails as unavailable, since the next act step continues the page as it is.
- A local build's `signedIn` step refuses a marker that one of the build's signed-out pages shows, with `marker_matches_signed_out_page`, and the sign-in stays open.
- A local sign-in no longer stops on a screen that shows a value the caller gave, such as a password screen that shows the typed email in its text, label or placeholder. Guardian's review of the step used to carry the screen as it was, so the check that keeps caller values out of reviewed source refused it with `SourceUnavailable` and the screen never ran. The screen now reaches Guardian through `screenMintText`, with each such value masked, and that check still refuses any value left. The review also tells Guardian that the host fills the login's values, which never appear in the review.
- `tldts` is 7.4.16 and `oxc-parser` 0.152.0, for the latest public suffix data and parser fixes. The new private suffixes `glideos.app`, `iqhs.pl`, `site.hosting-cluster.nl` and `site.webhosting.be` make each host under them its own site, as on `github.io`: two such hosts, or the suffix and a host under it, are no longer the same site. The source checks' parse results are unchanged. The optional `vitest` peer accepts any 5.x release from 5.0.2 (`^5.0.2`) instead of exactly 5.0.2.

### Fixes

- A local edit the minter can't apply now says the edit was not applied and why. That covers a patch that doesn't match, a file that already exists or is missing, and a file past the size or file-count limit. The file is unchanged, and no new folder is left behind. These edits no longer report "Workspace edit outcome unknown".
- The minter's `read_source` now reads local workspace files. Through 0.2.0 every local read failed as unavailable, because the local workspace refused the one extra byte the minter asks for to detect an oversized file. A file past 8 MiB is still refused.
- Local runs stage authored source a level below the SDK, as the workspace guide describes. The documented `../../runtime/index.js` import from `src/` and the skill references' imports now load. Integrations saved with `../runtime/index.js` still run unchanged.
- A private review that fails now forwards its final timing record to the host's model trace observer, as a successful one does. The record carries only the timing, never the error or other detail.

## 0.2.0

This release changes how a host embeds the minting core's authoring and which MCP entry a generated integration writes. Other standalone use through `pomerado`, `pomerado/mcp` and the CLI needs no change.

License: MIT from 0.2.0 (was AGPL-3.0-only through 0.1.2). No CLA.

### Breaking changes

- Authoring files carry standalone text with named sections, `<!-- pomerado:section ID -->`. Each ID starts with its file's key: the skill name in `<skill>/SKILL.md`, `agents.` in `workspace/AGENTS.md` and `guide.` in `workspace/README.md`. A section's standalone text, if it has any, is its default.
- `loadAuthoringSkills` and `loadWorkspaceGuide` from `pomerado/core/mint/skills` default to `"standalone"`, which renders each section's standalone text. `"hosted"` no longer renders host text from the package. It loads a directory the host composed first and refuses any section left in it.
  - Migrate by copying `getAuthoringDirectory()`, replacing every section with your own text, and loading the copy with an explicit `"hosted"`.
- The skill catalog lists only the skills the package ships: `core`, `auth`, `pagination`, `forms`, `writes` and `caller-input`. The `testing`, `recovery`, `captcha`, `browser-recovery`, `http-mcp` and `publication` entries are gone. The workspace guide installs only `README.md` beside `AGENTS.md`, without the four `reference/` sections. `writes` has one description in both modes.
  - Migrate by loading your own skills and reference sections beside the package's, in the order your model should see them.
- In `pomerado/core/runtime/provider-metadata`, `ProxySwitchSummary` is now `BrowserRecoverySummary` and `RetainedProxyError` is now `RetainedNetworkError`. Their shapes and values are unchanged.
  - Migrate by renaming the imports, or by declaring your own type of the same shape.
- `MintEntryNavigation`'s replaced-browser `reason` is open: `"sign_in"`, `"recovery"` or a reason the host defines and explains in `instruction`.
  - Migrate by giving any exhaustive check on `reason` a default branch.
- The optional `captcha_state` and `request_browser_recovery` tools get generic descriptions. `MintDependencies.hostToolDescriptions` takes a host's own.
  - Migrate by passing the descriptions your host relied on.
- A generated integration writes `mcp.json`, a standard `mcpServers` entry with no key, in place of `codex-mcp.toml`. Its README lists the add command for Claude Code, Codex and Gemini CLI.
  - `configPath` from `prepareIntegration()`, and `integration.configPath` in a finished `mint` job's output, now point to that JSON file instead of the TOML.
  - Authored source may no longer use these top-level names, compared case-insensitively: `mcp.json`, `.mcp.json`, `.vscode`, `.cursor`, `.codex`, `.gemini` and `.claude`. `deployment.json`, `mcp.mjs`, `readme.md` and `codex-mcp.toml` stay reserved.
  - Migrate by adding the integration with the command in its README, or by copying the entry in `mcp.json` into your client. Read `configPath` as JSON. Integrations minted earlier keep their TOML and still run.
- `MintFailure` adds the reason `definition_login_reference`. A host may refuse publication with it when a tool's definition quotes the build's account reference, and the agent is told which part to rewrite.
  - Migrate by giving any exhaustive check on `reason` a default branch.

### Other changes

- Seven headings that rendered empty in standalone mode now have standalone text, in `core/SKILL.md`, `auth/SKILL.md` and `workspace/AGENTS.md`.
- Section markers are checked strictly in both modes: an unterminated, unspaced, duplicated or foreign section, a stray end marker, a section inside a code fence and any other `pomerado:`, in any case, all fail the load.
- The `pomerado-mcp` bin starts when run through npx or a global install. Earlier versions exited without starting the server.
- The shared core skill suggests typed output: numbers for prices, amounts and counts with the currency or unit in its own field, ISO 8601 for dates and times, minutes for durations and one field per fact. These are suggestions, not checks.
- Guardian's question review allows a question about which sign-in method or account to use, or how to reach the sign-in, when the choices it names match what the page shows. The shared workspace guide says asking it is expected. Guardian also no longer rewords any question only because `allowedEffects` is empty.
- `ScriptQuestionDeclarations` refuses the whole record when any question id is invalid, instead of dropping that entry. A question id starts with a lowercase letter and uses only lowercase letters, digits and underscores, up to 64 characters.
- `MintDependencies.redactCallerText` lets a host remove private values, such as the build's account reference, from what the agent writes for its caller: a request's notice, prompts and option labels, and a blocked explanation. The agent's own transcript is unchanged.
- `MintDependencies.priorAttemptMayHaveChanged` tells the agent of a restarted write build that an earlier attempt may have changed the website, so it reads back before any write. A `not_opened` entry navigation may carry `reason: "prior_effect"` when the host skipped it for that reason.

## 0.1.2

- Guardian's upstream policy, adapted from OpenAI Codex, carries its Apache-2.0 notice, and the package ships `third-party/codex/LICENSE` and `third-party/codex/NOTICE`. Guardian drops the notice before the policy reaches the model.
- Failure-detail comments no longer name a hosted service's internal paths.
- `FailureSubCause` adds `browser_page_call_failed`, for a page command the browser answered with a failure, such as a script error or a timeout.
- This is the first release published with npm provenance.