updated README and a bunch of other stuff

docs/general-agent-guide.md

@@ -0,0 +1,57 @@
+
+## Require clarification and plan approval before making architectural code changes
+
+Before making any code changes which could be considered to influence the architekture of the application, you must follow this two-step process:
+
+### Step 1: Ask Clarifying Questions
+
+- Always ask at least one clarifying question about the user's request
+- Understand the full scope and context of what they're asking for
+- Clarify any ambiguous requirements or edge cases
+- Ask about preferred approaches if multiple solutions exist
+- Confirm the expected behavior and user experience
+- Ask the clarifying questions by numbering them, so the user can number their replies.
+
+### Step 2: Present Implementation Plan
+
+- After receiving clarification, present a detailed implementation plan
+- Break down the work into specific, actionable steps
+- Identify which files will be created, modified, or deleted
+- Explain the technical approach and any architectural decisions
+- Highlight any potential risks, trade-offs, or dependencies
+- Estimate the complexity and scope of changes
+- **Wait for explicit user approval** before proceeding with any code changes
+
+### What are considered architectural changes
+
+**Architectural** (clarify → plan → wait for approval), for example:
+- New parts, or new cross-part `method` / `opt` surfaces
+- Wiring one part into another (e.g. UI shell calling `auth.client.login`, soft-notify via `has_part`)
+- Changes to core loading / `has_part` / part-system semantics
+- Splitting or merging capabilities across part boundaries
+
+**Not architectural** (implement directly when the intent is clear), for example:
+- Layout / CSS / copy tweaks in an existing screen
+- Adding another display line or button that only uses existing local state or already-exposed methods
+- Bugfixes that don’t change the part API (e.g. `document::Style` re-render warnings)
+
+### Approval Requirements
+
+- User must explicitly approve the plan with words like "yes", "approved", "proceed", "go ahead", or similar
+- If the user suggests modifications to the plan, incorporate them and seek re-approval
+- Do not assume silence or ambiguous responses mean approval
+
+### Exceptions
+
+- This process may be skipped only for trivial changes like fixing obvious typos or formatting
+- When in doubt, always follow the full process rather than assuming an exception applies
+
+### Example Workflow
+
+1. User: "Add a login form to the app"
+2. Assistant: "I'd like to clarify a few things about the login form: [questions]"
+3. User: [provides answers]
+4. Assistant: "Based on your requirements, here's my implementation plan: [detailed plan]. Does this approach look good to you?"
+5. User: "Yes, that looks good"
+6. Assistant: [writes plan to file].
+7. Assistant: [proceeds with implementation].

docs/part-system.md

@@ -1,15 +1,5 @@
 # Mize Part System (LLM generated guide)
 
-## Overview
-
-Mize is built around a **parts architecture** that allows you to compose functionality modularly. Each part is a self-contained unit that can:
-
-- Store and manage its own state
-- Expose methods to other parts
-- Register itself with the Mize instance
-- Define configuration options
-
-Parts are the primary way to extend Mize's functionality. The system is designed so that parts can depend on each other, and users can enable/disable parts as needed.
 
 ---
 

docs/plans/2026-11-03-dist-publish.md

@@ -0,0 +1,18 @@
+# Plan: dist publish + dist.mize.works (approved)
+
+## Config
+- `parts.workspaces`: list of dirs; each subdir is a part to build/upload
+- `parts.dist.cd`: bool; when true artifact uses `-cd` instead of `-{version}`
+
+## Publish (`mize.dev`)
+- After build: pack each part `.so` under `lib/`, special part `mize` gets `libmize.so` + `bin/mize`
+- Hash via `get_part_hash` with modName, system (target), mize_version
+- Filename: `{hash}-{id}-{version}.tar.gz` or `{hash}-{id}-cd.tar.gz`
+- rsync to `ocib:host/mize-dist/`
+
+## fetch_part
+- Base URL `https://dist.mize.works/`
+- Same naming; ensure mize_version in selector
+
+## ocib
+- `~/host/docker-compose.yaml`: Traefik + kugland/darkhttpd serving `mize-dist` for `dist.mize.works`

docs/plans/2026-11-04-load-part-at-instances.md

@@ -0,0 +1,14 @@
+# load_part_at instances (priv.spacetime / ppc.spacetime)
+
+Approved 2026-11-04.
+
+## Goal
+Instantiate the same `spacetime` `.so` under different part ids (`priv.spacetime`, `ppc.spacetime`), each with its own config namespace. Dependents use `Spacetime::get("priv.spacetime")` etc.
+
+## Changes
+1. Platform `load_part(part_name, path, at_id)` via `get_global_mize()`; save/restore `cur_eval_part`.
+2. Rename `Mize::load_part_at` → `load_part_from_path`.
+3. `config::load_part_at(at_id, part_name)` — no-op in generate mode.
+4. Codegen: special SpacetimeDB client gen when `gen` contains `"spacetime"`, module at `{cwd}/spacetime` if present.
+5. `sci`: `gen += spacetime`, `load_part_at("priv.spacetime", "spacetime")`.
+6. New `mize/parts/ppc`: loads `ppc.spacetime`.