Mize

Mize is many things.

a "strongly typed filesystem for the age of everyone having many devices"
a stdlib replacement
a framework to make malleable/extensible/configurable/debugable software fast
a OS userspace (mainly linux but later also any other kernels)
a library for COP = Configuration Oriented Programming
a thing providing one single API through which any data can be interacted with

Codebase Structure

packages/
├── src/           # Core Mize framework (Rust)
├── marts/         # Mize parts collection (Rust/TypeScript)
└── macros/        # Mize macros

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

User: "Add a login form to the app"
Assistant: "I'd like to clarify a few things about the login form: [questions]"
User: [provides answers]
Assistant: "Based on your requirements, here's my implementation plan: [detailed plan]. Does this approach look good to you?"
User: "Yes, that looks good"
Assistant: [writes plan to file].
Assistant: [proceeds with implementation].

3.4 KiB Raw Blame History