feat(local): decide local stays app territory

Define local/offline truth as commands, domain events, and projections rather than stored DOM patches or EffectBatch payloads; wire the techdemo through a local command-to-projection-to-effect flow; document that hemx-local is not a crate until reusable semantics are proven.

req: local/001

req: local/002

req: local/003

req: local/004

req: examples/001

AGENTS.md

@@ -55,4 +55,5 @@ Keep it stable. Prefer pointers to canonical sources over copied structure, file
 - Hemlate examples must use real hemplate syntax, not Vue/Handlebars sketches: `{+ expr +}` for escaped text, `{+= expr =+}` only for trusted/rendered HTML, `+attr="expr"` for dynamic attributes, and Rust-shaped `h-if`, `h-for`, `h-match`, `h-case` directives (`h-case="_"` is the default arm).
 - JS runtime changes must preserve root-scoped lookup and avoid selectors, VDOM, expressions, and per-node listeners.
 - Host capability adapters must stay at the `hemx-host` boundary: they may call host APIs and return host events, but they must not mutate DOM or own app/domain state. req: host/002
+- Local/offline app behavior should be commands/events/projections; do not add `hemx-local`, stored DOM patches, or stored `EffectBatch` truth without a proven reusable contract. req: local/001 req: local/002
 - Axum apps should serve and load the shared runtime through hemx-axum helpers such as `runtime_js_path()` and `runtime_js()`, not hard-coded `/hemx.js` URLs or app-owned cache-busting strings.

REQUIREMENTS.md

@@ -578,7 +578,7 @@ what a valid business email is.
 001	Local/offline behavior is represented as app commands, domain events, and projections. Stored DOM patches or stored EffectBatch payloads are not the source of truth.
 
 ### req: local/002
-002	Local command logs are app or integration territory until a reusable hemx contract proves common semantics across multiple apps. hemx core must not gain a mandatory browser database, client store, sync engine, or conflict policy.
+002	Local command logs are app or integration territory until a reusable hemx contract proves common semantics across multiple apps; `hemx-local` is not a crate yet. hemx core must not gain a mandatory browser database, client store, sync engine, or conflict policy.
 
 ### req: local/003
 003	Replaying local work back to a server or peer sync target is explicit app/integration policy. A local projection may render immediate feedback, but server acceptance, rejection, reconciliation, export, and deletion rules remain visible product decisions.

docs/recipes/local-command-log.md

@@ -5,6 +5,22 @@ sync framework. The local artifact is an app-owned command/event log plus a
 projection; hemx effects are rendered output, not stored truth. req: local/001
 req: local/002
 
+## Decision: no `hemx-local` crate yet
+
+`hemx local` remains an app/recipe pattern for now, not a reusable hemx layer.
+The host capability path proves that thin typed contracts work when the shared
+semantics are obvious: manifest, call, event, and host-check failure. The local
+exemplar proves a safer boundary for offline work: command, domain event,
+projection, then `EffectBatch`. It does not yet prove common storage,
+reconciliation, export, deletion, or conflict semantics across apps, so a crate
+would freeze product policy too early. req: local/002 req: local/003 req:
+local/004
+
+A future reusable layer must first prove at least two independent apps share the
+same command-log contract without sharing domain policy, storage provider, sync
+provider, or conflict rules. Until then, recipes and app-owned integrations are
+more honest and easier to delete. req: local/002 req: local/003
+
 ## Shape
 
 ```text