updated README and a bunch of other stuff

AGENTS.md

@@ -8,74 +8,17 @@ Mize is many things.
 - a library for COP = Configuration Oriented Programming
 - a thing providing one single API through which any data can be interacted with
 
+All code written for, with or as part as mize (except for the small core) is written as a Mize Part. ALWAYS referr to:
+@./docs/general-agent-guide.md
+@./USING-MIZE-FOR-AGENTS.md
+
+unless instructed otherwise put new parts into `./parts/vibed.<id-of-part>`.
+
 ## Codebase Structure
 
 ```
-packages/
-├── src/           # Core Mize framework (Rust)
-├── marts/         # Mize parts collection (Rust/TypeScript)
-└── macros/        # Mize macros
+core/     # Core Mize framework (Rust)
+parts/    # Mize parts (cdylibs / crates)
+macros/   # Proc macros
+docs/     # documentation
 ```
-
-## Important
-- usage of any git commands is strictly forbidden!
-- in case it takes too long finding smth or figuring smth out. stop and ask the user. (goal is not to do stuff as autonomous as possible)
-
-## Key Components
-
-All code written for, with or as part as mize (except for the small core) is written as a Mize Part. see `docs/part-system.md` for how that works.
-
-To understand the main components of the architecture you can refer to `docs/architecture.md`.
-
-Any proc macros should go into `./macros`.
-the core mize library is in `./core`
-any mize parts are in `./parts` or in their own repositories.
-
-## 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
-TODO: add better examples.
-
-eg: adding a seccond line displaying a different value from the DB is not considered architectural. as it was achievable by only modifying the existing function and rsx! code.
-
-### 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].