packages

Begin with an explicit responsibility

Select entries for the task at hand. Reading configuration does not require starting remote connections or a telemetry runtime. Publishing a remote file can then compose connection, transfer and file-verification capabilities. The five packages are not stages that every task must pass through.

A package owns its promised call behavior, outcome interpretation and resource settlement; the product chooses targets, authority and data relationships. For example, after Remote transfers and publishes a file, service activation and rollback remain product decisions. A Yaostate transaction does not perform external payments or notifications on the product’s behalf.

Choose the smallest capability set for the actual task

Configuration parsing needs only Base’s strict input and value handling. Remote adds connections and complete transfers when a file must be delivered elsewhere. System is needed when the caller must own a process, mount, network resource or VM lifecycle. Yaostate provides transactions for durable business state; Telemetry supplies an independent observation path.

Before choosing a package, define the output: checked configuration, a remotely visible file, a running object that still needs an owner, or a committed database result. They have different completion conditions and cannot all be reduced to one success Boolean.

1. Prepare and publish material

   Base checks local material and stable content. Remote completes the selected transfer and visibility switch. The business separately chooses durable synchronization or receiver activation.

2. Run and settle work

   System or Remote returns actual execution and closure outcomes. Retain any owner that still has work to settle; a timeout does not mean the resource was released.

3. Persist business relationships

   Yaostate atomically commits caller-defined relationships and indexes. Payments, notifications and external file writes remain at their respective effect boundaries.

Select packages by task; the arrangement implies no dependency or startup order. Products retain business authorization, data models and external effects.

Call a capability for a complete task

For configuration, Base performs strict decoding that rejects unknown fields and duplicate declarations while retaining explicit paths, sizes and deadlines. Content verification reaches the actual end of the file before producing its digest. A retained file handle fixes object identity; the caller must still maintain stable bytes.

Remote executes a command with explicit arguments, environment and output, then settles the channel and both output streams before returning a complete result. Its in-process SSH profile serves trusted networks. The OpenSSH entry uses an explicit known_hosts file when expected-host verification is required. Connect remote calls over SSH retain their logical destination and HTTPS verification.

System starts programs in selected namespaces, which provide scoped system-resource views, retains exact interfaces and mounts, or transfers boot, disk and network bindings to a VM. Address service, boot-information proxy, TFTP file transfer and DNS forwarding each declare resource limits and close independently.

Retain resource ownership and observation context

Once a resource is acquired, its actual owner remains responsible for settlement. Child exit and IO completion are separate facts, and ordinary child control does not include every descendant. Descendant containment requires an actually delegated scope. Failure or cancellation preserves acquired resources with their original owner.

VM control likewise distinguishes native running state, guest stop, host-process termination and a guest program’s result. A remote timeout does not establish that no remote effect occurred. Continued closure retains the original connection and responsibility; reconnecting and resending cannot turn an unknown result into a known one.

Telemetry records trace context: the relationship between a call and its upstream or downstream work. HTTP response headers, body completion, errors and abandonment remain distinguishable, while Connect reuses the same observation. The caller chooses whether to trust an upstream parent or retain only an untrusted link. Authentication and an internal source do not automatically promote trust.

Deliver complete material before selecting activation

Base uses explicit staging, verification and publication to deliver files. Atomic visibility lets a reader see either the old file or the complete new one. Durability additionally requires the applicable file and parent-directory synchronization. A verified result remains reusable only under continuing identity and byte-stability premises.

Remote stages within the target directory, transfers complete content, sets its mode and performs an atomic rename. That establishes a remote visibility change. Readback, durable synchronization, service activation and business rollback belong to the selected operation. HTTP and RPC calls over the connection retain their own request and result meanings.

Local state commits through durable batches. A storage failure that requires reopening first fences new work, then reestablishes current observation from the same root. Reopening can answer what is stored now; identical content does not reconstruct the receipt of an earlier write whose response was lost.

Preserve both definite and unknown transaction outcomes

Yaostate gives business declarations bounded fields, stable Space identities and ordered keys, with point reads, batch reads and bounded pages. Multiple Spaces in one database can commit atomically. The business reads and validates uniqueness, references and index conditions in that same write transaction. Pages across transactions use new snapshots rather than one fixed export view.

Ordinary transactions distinguish definite noncommitment from unknown outcomes. Optional Once request-result recording persists the complete input, output and business writes together so the same request can recover its original output. A handler may execute more than once, so it uses only the supplied transaction and stable inputs, without messaging, payment calls or external file writes.

An unresolved result retains its original database, operation, request identifier and input. Shutting down the runtime does not prove that the transaction failed to commit, and an absent record does not prove that later completion is impossible. Model changes use stopped writes, a read-only source, bounded conversion, business validation and explicit cutover. Result retention and reclamation remain business decisions.

Return enough facts and ownership with an error

An acquisition failure distinguishes no acquired resource from residual resources that still need settlement. A mutation failure distinguishes definitely not applied from an indeterminate effect. Callers use those facts to choose subsequent work instead of guessing from an error name. The original deadline bounds the same task; waiting again or obtaining a handle again does not renew it.

For example, an ordered batch of remote uploads can leave a completed prefix after failure; that is not an all-or-nothing rollback. An unknown database commit does not become uncommitted when the client closes. Recovery retains the original destination and business identity, obtains the relevant actual result and leaves the next decision with the business.

• Usable evidence: the completion scope explicitly returned by the capability

  A complete transfer, committed transaction and settled resource each have their own result. Compose the business workflow using that actual scope.

• Unsupported conclusion: stopping a wait removes remote effects

  A command, write or commit may already have happened. Original work retains responsibility for remaining resources and uncertain effects.

• Check next: external effects inside a Once handler

  The handler may run again and uses only the supplied transaction and stable input. Payments, messages and file writes cannot be hidden inside a retryable transaction function.

Compare actual calls with independent outcomes

Verification uses public entries to consume actual material and results. System’s reusable test-system image and separate input image support checks involving global resources. Yaostate’s real isolated database permits client restart against one retained history. Remote’s SSH test VM checks actual connection, command and transfer relationships. Callers supply independent business expectations.

Telemetry uses official bounded exporters. A full queue or unavailable receiver leaves gaps rather than proof that no failure occurred. Authorized relays preserve original producer identity, and shutdown settles producers before their export responsibility. The design’s verification concerns include actual dispatch targets, independent readback, ownership after failure and incomplete results; logs or one acknowledgement cannot replace the required evidence.