new: update README and SaveOption for skeleton

Author: nick1udwig

src/new/templates/rust/ui/hyperapp-skeleton/README.md

@@ -12,20 +12,15 @@ Insert your app spec here, e.g.:
 Todo List with P2P Sync.
 A collaborative TODO list where items sync between nodes.
 
-Write a spec, and then implement it step by step. Use the README.md given in hyperapp-skeleton to find instructions on specific details.
-At the end, I should be able to run `kit bs —hyperapp` and manually test that the app works.
+Write a spec, and then implement it step by step.
+Use the README.md given in hyperapp-skeleton to find instructions on specific details.
+At the end, I should be able to run `kit build --hyperapp && kit s` and manually test that the app works.
 ```
 
 The rest of this document is aimed at *LLMs* not *humans*.
 
 ## Quick Start
 
-### Prerequisites
-
-- Hyperware development environment (`kit` command)
-- Rust toolchain
-- Node.js and npm
-
 ### Building
 
 Always build with
@@ -61,7 +56,8 @@ hyperapp-skeleton/
 
 ### 1. The Hyperprocess Macro
 
-The `#[hyperprocess]` macro is the core of the Hyperapp framework. It provides:
+The `#[hyperapp_macro::hyperapp]` macro is the core of the Hyperapp framework.
+It provides:
 - Async/await support without tokio
 - Automatic WIT generation
 - State persistence
@@ -79,7 +75,7 @@ async fn my_endpoint(&self) -> String {
 ```
 
 #### Remote Requests
-All remote requests must use `.expects_response(30)`, where the value 30 sets a 30‑second response timeout.
+All remote requests must set `.expects_response(time)`, where `time` is the response timeout, in seconds.
 ```rust
 let req = Request::to(("friend.os", "some-hyperapp", "some-hyperapp", "publisher.os"))
     .expects_response(30)
@@ -101,7 +97,8 @@ Parameters must be sent as tuples for multi-parameter methods:
 ```
 
 #### Frontend keys in snake_case
-All keys in TypeScript need to stay in snake_case (`node_id`), camelCase (`nodeId`) will break the app!
+All keys in TypeScript need to stay in snake_case (e.g. `node_id`).
+camelCase (e.g. `nodeId`) will break the app!
 ```typescript
 export interface StatusSnapshot {
     node_id: string;
@@ -154,7 +151,7 @@ Add system permissions in `pkg/manifest.json`:
 "request_capabilities": [
     "homepage:homepage:sys",
     "http-server:distro:sys",
-    "vfs:distro:sys"  // Add as needed
+    "vfs:distro:sys"
 ]
 ```
 
@@ -182,47 +179,29 @@ If sending messages between nodes, set:
 - Check that the app is running in Hyperware environment
 
 ### WIT Generation Errors
-- Use simple types or return JSON strings
-- No HashMap (use Vec<(K,V)>)
 - No fixed arrays (use Vec<T>)
 - Add #[derive(PartialEq)] to structs
 
-### Import Errors
-- Import the most important structs and functions from `hyperware_process_lib`, e.g. `Request`, `LazyLoadBlob`, `ProcessId`
-
-### manifest.json missing
-- Run `kit b --hyperapp` to generate it
-
 ### Naming Restrictions
 - No struct/enum/interface name is allowed to contain digits or the substring "stream", because WIT doesn't allow it
 - No record/variant/enum name is allowed to end with `Request`, `Response`, `RequestWrapper`, `ResponseWrapper`, because TS caller utils are autogenerated with those suffixes
 
 ## Instructions
 
-### Create an implementation plan
-
 Carefully read the prompt; look carefully at `instructions.md` (if it exists) and in the example-apps directory.
-In particular, note the example applications `example-apps/sign/`, `example-apps/id/`, and `example-apps/file-explorer`.
-Note that `file-explorer` example contains an `api` folder, which is generated by the compiler, and not human or LLM written.
-`sign` and `id` demonstrate local messaging.
-`file-explorer` demonstrates VFS interactions.
-
-Note in particular that bindings for the UI will be generated when the app is built with `kit build --hyperapp`.
-As such, first design and implement the backend; the interface will be generated from the backend; finally design and implement the frontend to consume the interface.
-Subsequent changes to the interface must follow this pattern as well: start in backend, generate interface, finish in frontend
-
-Do NOT create the API.
-The API is machine generated.
-You create types that end up in the API by defining and using them in functions in the Rust backend "hyperapp"
 
-### Implement the plan
+In `example-apps/`:
+- `sign` and `id` demonstrate local messaging.
+- `file-explorer` demonstrates VFS interactions.
+  The `file-explorer` example contains an `api` folder, which is generated by the compiler, and not human or LLM written.
 
-Look carefully at `IMPLEMENTATION_PLAN.md` and in the `example-apps/` directory, if relevant.
+Look at the `hyperware_process_lib` and in particular at `hyperapp`.
+If not provided with local repo look at https://github.com/hyperware-ai/process_lib/tree/main/src and https://raw.githubusercontent.com/hyperware-ai/process_lib/refs/heads/main/src/hyperapp.rs
 
-Work from the existing template that exists at `hyperapp-skeleton/` and `ui/`.
+Work from the existing template, whose backend lives at `my-app-name/` and frontend at `ui/`.
 
-Note in particular that bindings for the UI will be generated when the app is built with `kit build --hyperapp`.
-As such, first design and implement the backend; the interface will be generated from the backend; finally design and implement the frontend to consume the interface.
+Bindings for the UI will be generated when the app is built with `kit build --hyperapp`.
+Thus, first design and implement the backend; the interface will be generated from the backend; finally design and implement the frontend to consume the interface.
 Subsequent changes to the interface must follow this pattern as well: start in backend, generate interface, finish in frontend
 
 Do NOT create the API.
@@ -231,10 +210,11 @@ You create types that end up in the API by defining and using them in functions
 
 When sending p2p always send using `hyperware_process_lib::hyperapp::send` or `hyperware_process_lib::hyperapp::send_rmp` when expecting a Response, never `.send_and_await_response`.
 Example usage of `send` and `send_rmp` are shown in example_apps.
-If not expecting a response, use `.send`.
+If not expecting a response, use `hyperware_process_lib::Request::send`.
 
-Do not worry about serialization/deserialization when using `send` and `send_rmp` functions for p2p communication.
-Notice that this all happens within those functions: just take the rust types as args and return rust types as return values.
+`send` and `send_rmp` handle (de)serialization.
+Just put Rust types as args and return Rust types as return values.
+Do not return String or JSON if a more specific Rust type will work.
 
 If you create a GUI for the app you MUST use target/ui/caller-utils.ts for HTTP requests to the backend.
 Do NOT edit this file: it is machine generated.

src/new/templates/rust/ui/hyperapp-skeleton/hyperapp-skeleton/src/lib.rs

@@ -40,7 +40,7 @@ pub struct Status {
             config: hyperware_process_lib::http::server::HttpBindingConfig::new(false, false, false, None),
         },
     ],
-    save_config = hyperware_process_lib::hyperapp::SaveOptions::EveryMessage,
+    save_config = hyperware_process_lib::hyperapp::SaveOptions::OnDiff,
     wit_world = "hyperapp-skeleton-template-dot-os-v0"
 )]
 impl AppState {