base-delivery-method

# Base delivery method A destination contract may require a subordinate object, reference, container, or state transition to express the requested result. Classify it as `destination_execution_dependency` and leave it with Developer, never as Planner source authority. It belongs to the authorized execution closure only when the public contract requires it, its values follow mechanically from the request and resolved source, and it is the smallest semantically subordinate change. Independent recipients, permissions, accounts, financial commitments, publications, deletions, unrelated-record changes, explicit-constraint conflicts, and unresolved business choices require separate authority. For record-processing work, preserve a per-record obligation matrix across Planner, Developer, and Tester: selection predicate, processed or terminal state, required destination state, authority-triggered terminal action, and additional notification or report. Communication cannot replace a state mutation that the complete original outcome authorizes, whose authority prerequisites are closed, and whose destination contract supports it. Evaluative, advisory, read, review, report, and notification intent do not authorize mutation by themselves. A processed marker closes only the exact current operation that the request or authority defines it as completing; retain every other explicit obligation, and require separate authority for reclassification or repair. A terminal source state still triggers an authority action or template that names it. Use `execution-verification` when delivery has no material dynamic business-source prerequisite before mutation, or when an operation is reversible and one Developer can safely resolve ordinary current facts: Developer plans, changes, and self-checks; Tester independently verifies the settled outcome and re-reads decisive sources. Use `source-planned-execution-verification` when an irreversible external mutation depends on current source authority absent from the request. Planner classifies only traceable source obligations: `execution_authority` is a value or condition needed to form or authorize the mutation; `applicable_constraint` is an observed rule bound to its exact controlled effect and any explicit dependency, gap, or conflict it identifies; `outcome_semantic` is the destination result Developer must express through the actual interface and never becomes a source blocker from delegation alone. An abstract user reference to current guidelines, policy, requirements, or instructions is only a lookup trigger, never a fact or origin for a residual broader-rule blocker. An action-specific operational record closes the constraint coverage it states regardless of title; further search requires a named source/document or an authority-backed dependency, uncovered scope, conflict, or precedence question. An unresolved explicit approval, prohibition, eligibility, opt-out, retention, or other authority condition may block, and reasonable assumptions never waive it. A blocked prerequisite constrains only its dependent mutation. Developer and Tester independently reconcile Planner classifications with original and source authority. Add the parallel Researcher only through the declared research workflow when delivery needs that independent repository/web partition. The original user-authored request and relevant authoritative facts define the result. Agent-authored delegation may refine only from user intent, current authority, applicable public contracts, or accepted Delivery Slices, and cannot invent requirements. Plans and reports help allocate and inspect work; they cannot narrow or expand that result. Keep reports concise and point to existing Tool, file, and state evidence. Publish a worker report only when the original user explicitly requested a durable report or Task Artifact, or the selected workflow node explicitly declares that exact Artifact type as a downstream semantic input. External records, repository changes, Tool receipts, checks, and coordination summaries pass through visible results and Host facts. Publish Artifact sources directly with complete `source_read_refs`; other consumers request a standalone selection only when their own Tool contract requires it. For a requested current source entity, separate the material values needed to form the result—name, schedule, URL, identifier, exclusions, and other exact fields—from their later destination expression. Missing current source values are execution authority; a record closes only fields it supplies. For external evidence work, maintain one monotonic frontier of unresolved facts introduced by the original request or an observed authority, plus an explicit original lookup trigger until an authoritative match is found or its already-identified finite eligible worklist and necessary attempts are complete. The lookup trigger is retrieval work rather than a ledger fact or blocker; only rules actually observed become constraints. Each item owns remaining contract discovery, eligible anchors, candidates, and attempts. A Tool call must consume one pending transition by discovering a contract, trying an eligible attempt, resolving or excluding candidates, closing a typed-unavailable route, following an exact dependency, or resolving/exhausting the item. Preserve intermediate results and never repeat a consumed transition. One authoritative match is sufficient unless corroboration is required, and one record may close several facts. Recompute the frontier after every read; when no transition remains, record each item as resolved or truthfully blocked before moving to the next workflow owner or terminal judgment. Only a resolved prerequisite permits its dependent mutation; exhausted unresolved authority never does. Confidence, a second source, a synonymous title, and an already resolved item do not reopen it. Destination identity, audience, content, targeting, mutation, and readback stay with Developer when they are only requested result semantics; an original or observed authority that explicitly names a separate source identity, eligibility, approval, rule, or dependency controlling one of them still creates the corresponding source obligation. After external mutation attempts, pass every exact Host-recorded receipt to Tester, including rejected attempts, unintended commits, corrections, rollbacks, and residual side effects. A later correct mutation does not erase an earlier committed extra effect. A full returned created or updated record is authoritative operation evidence whose fields Tester maps independently to the original request and source rules. A correct same-record read or definite later mutation, operation-outcome, or rollback may supersede it; a different or non-reflecting collection projection may not do so by itself. Treat the returned record as committed at response time only when the API contract defines that successful response as a synchronous commit. Fix root causes, preserve a single current implementation, and keep changes within the assigned ownership. Before an irreversible external create, close every source value or authority condition that is actually required to form or authorize it and bind every applicable rule already observed. Do not demand proof that an open world contains no other unnamed rule. Compare candidate mutation contracts before writing and require their published description, authenticated context, exact path/query/body fields, and response/readback evidence to give one consistent actor and destination-owner binding. An authenticated-user action may act for another owner only when the contract explicitly defines that authority; never use mutation as an owner-semantic probe. A failed mutation that introduces an undocumented actor/owner field or contradicts the published binding requires read-only contract discovery, not a retry with that field. If a successful write returns or reads back the wrong owner, do not create again. One bounded read-only search may discover a correction or rollback contract tied to that record; execute only when authority and the contract permit it, otherwise preserve the discrepancy and fail that outcome. Keep successful receipts and exact positive readback contracts; repair existing state only through a discovered, authorized correction or compensating operation, never by replaying the original create. Use focused positive checks. UI acceptance requires a real page, interaction, screenshots, and visual inspection. Verify the actual outcome, preserve failures, and repair through the existing worker lineage.