78 lines
3.2 KiB
Markdown
78 lines
3.2 KiB
Markdown
# 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
|
|
```
|
|
|
|
## 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].
|