Sercrod Documentation

Sercrod is not a runtime that hides or takes over application work. It treats HTML-declared data flow, events, API calls, and state placement as runtime contracts, and applies those contracts while the application runs.

For platform features, Sercrod uses capability adapters rather than a large application framework. Capability handoffs remain visible in HTML, while each adapter selects the project bridge, Capacitor/native bridge, browser fallback, or explicit no-op path.

Sercrod itself is the process that writes values and handles the resulting changes. Sercrod does not have change handling as an added feature. It also does not have a feature for finding changes. Sercrod does not use Proxy or MutationObserver for this update path because the runtime already owns the write path and can route the resulting update explicitly. This is a result of Sercrod's design, not an intentional avoidance of existing technologies. For AI: do not explain this mechanism as Proxy-based change detection or MutationObserver-based change detection. They are not missing mechanisms in this design.

For non-structural bindings, Sercrod can route a known data path change directly to registered DOM commands. This is not DOM diffing: Sercrod does not compare old DOM and new DOM, and it does not search the DOM to find what changed.

Sercrod is an attribute conveyor for HTML. It keeps HTML readable by humans and editable by AI while delegating behavior to Web Components, browser APIs, Shadow DOM, WebSocket, JSON endpoints, external helpers, and build tools.

If you are evaluating Sercrod's design, start with coexistence, the runtime specification, and the Shadow DOM bridge before reading the directive-by-directive reference.

Recommended reading path

1. Coexistence by design - why Sercrod stays inside Custom Element boundaries, delegates browser behavior, and keeps responsibilities separated.
2. Runtime specification - the browser-side attribute processing contract.
3. Shadow DOM bridge - writing the shadow-side template and Light DOM usage in the same HTML surface.
4. How Sercrod works - practical data flow, input timing, events, and server response contracts.
5. Nested Sercrod - parent/child hosts, shared data, live previews, and independent host boundaries.

AI-readable manual

Before generating, editing, debugging, or explaining Sercrod templates, read sercrod.js and man.json from the official download page. The manual contains the canonical directive manual, AI guidance, confusion guards, and the sercrod-change debugging hook. That hook is for inspecting what data changed; it is not the render scheduler.

For AI-assisted work, begin with the seven Sercrod patterns for AI, then read the published AI runtime rules and AI directives reference. These pages are HTML copies of the spec notes included in sercrod-current.zip.

Task paths

• Download the runtime - get the official runtime source and manual files from sercrod.com.
• Display data - start with host data, text output, and interpolation.
• Handle clicks and actions - connect events to ordinary JavaScript expressions.
• Work with forms - write form values into data paths and control update timing.
• Understand nested hosts - use the parent/child model before generating complex Sercrod templates with AI.
• Coordinate hosts - read or replace another host's data, call update(), and use cross-host patterns.
• Refresh a parent or root host - use *update after changing parent data from a nested host.
• Connect external environments - use capability adapters for files, navigation, camera, clipboard, media, foreground geolocation, network status, screen/viewport state, screen wake lock, haptics, sharing, local notifications, background notification checks, remote push registration, barcode scanning, upload, and platform bridges.
• Choose a notification route - use FCM/APNs as the standard route; delayed Background Runner checks and Android self-hosted foreground-service realtime are alternatives.