Lifecycle, Ownership, and Security

Status: implemented Core and adapter boundary; some platform behavior is environment-dependent.

Sercrod lifecycle is about responsibility. A host releases the resources it created or registered; it does not take ownership of unrelated application or browser state.

Ownership answers cleanup questions

An owner creates or holds a long-lived resource such as an external instance, subscription, temporary browser object, or host-level connection. A reference can request work from that owner, but does not become a second owner merely by using the same capability.

This distinction keeps cleanup predictable:

owner created resource or subscription
  -> reference performs an explicit action
  -> replacement or owner removal releases owner-owned state
  -> host teardown releases remaining host-owned state

An adapter retains library-specific disposal work. Core retains the common owner, response-placement, diagnostics, and removal boundaries. An operation must not silently retain an unsafe native object, subscription, or temporary resource in application data.

Host and resource lifetime

On host disconnection, Core cleans up registered window-level keyboard handlers, WebSocket connections, navigation state, diagnostics state, and external capabilities. Structural removal also matters: an owner can disappear while its containing host remains connected, so resource cleanup cannot depend only on whole-host teardown.

Temporary resources follow the same rule. For example, a browser fallback that creates a file input, object URL, temporary anchor, or clipboard textarea owns that object and releases it after the terminal operation. Caller-authored elements and unrelated listeners remain application-owned.

Capability-specific subscriptions must have a matching disposal path. The exact creation and reverse-cleanup order belongs to the relevant capability contract; it is not a generic order that this page invents.

Results and failures stay separate

*response is the only common placement path for an allowed result. A failed operation, unsafe return, invalid destination, permission stop, or unavailable backend is not a successful result and must not be placed as one.

External capability routing accepts only safe, finite plain result values for placement. Native instances, DOM objects, functions, chains, subscriptions, and library-specific unsafe objects remain outside application data. A response placement failure remains a failure at the response boundary; it does not turn the action into success.

Where a covered capability reports an error, the existing diagnostics path and bounded sercrod-error reporting are used. This does not authorize a new event name or a general event system.

Diagnostics is bounded operational evidence

Diagnostics can collect selected Sercrod and browser-originated failures for a host, serialize them safely, redact sensitive detail, deduplicate and bound them, and send them through an application-provided transport path.

Diagnostics does not own analytics, user profiling, a server, retention policy, access control, console-history scraping, DOM snapshots, form values, storage dumps, request bodies, Playwright orchestration, or native OS logs. Those responsibilities remain with the application and operator.

Explicit diagnostics clear and host teardown are different paths. Clear may flush and report its explicit action; host teardown stops listeners and timers, drops queued local work, and does not begin retries or emit completion into a disposed host.

Trusted-content boundary

Templates, expressions, expression-based data, registered methods, and HTML-producing directives are trusted code paths. They are not safe for arbitrary external text.

For user-controlled values, prefer *print or *textContent. Use *innerHTML or *compose only with trusted or appropriately sanitized HTML. Likewise, an application validates server responses before treating them as trusted HTML. Sercrod does not supply the application's authentication, authorization, retention, or content-sanitization policy.

Environment boundary

Browser, Capacitor, and Tauri backends can share a capability contract without forcing identical native behavior. Permission UI, browser support, WebView behavior, external services, and Windows Tauri integration remain environment-dependent where the evidence says so.

Evidence

Status: implemented, with environment-dependent platform boundaries.

Evidence: docs/spec/runtime.md — Cleanup and Security, docs/reference/lifecycle.md, docs/reference/warnings-and-errors.md, docs/spec/diagnostics-adapter-design.md, architecture Section 16.60–16.61 and Section 21.22, and focused tests in sandbox/app/diagnostics/test/adapter.test.js, sandbox/app/diagnostics/test/directive.test.js, sandbox/app/map/test/directive.test.js, sandbox/app/tensor/test/directive.test.js, and sandbox/app/todo/test/save-load-fallback.test.js.