typed_use_cases 0.1.2

Formalize use cases at the type level. Zero runtime overhead. Experimental proof-of-concept.
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136

# Contributing to typed_use_cases

Thank you for your interest in contributing to `typed_use_cases`!

## Development Setup

1. Clone the repository:
```bash
git clone https://github.com/yourname/typed_use_cases
cd typed_use_cases
```

2. Build the project:
```bash
cargo build
```

3. Run tests:
```bash
cargo test --all
```

4. Run the example:
```bash
cargo run --example ecommerce
cargo test --example ecommerce
```

## Project Structure

- `src/` - Main library code
  - `lib.rs` - Re-exports and public API
  - `traits.rs` - Core traits (Actor, Entity, DependentEntity, UseCase)
  - `macros.rs` - implement_all_use_cases! macro

- `typed_use_cases_derive/` - Procedural macros
  - `src/lib.rs` - #[derive(Actor)] and #[derive(Entity)]

- `examples/` - Examples
  - `ecommerce.rs` - Full e-commerce use case example

- `tests/` - Integration tests

## Code Quality Standards

### Tests

All changes must include tests:
- Unit tests for new functionality
- Integration tests for end-to-end scenarios
- Doctests for public API examples

Run tests with:
```bash
cargo test --all
```

### Documentation

All public APIs must be documented:
- Public traits, types, and functions need doc comments
- Include examples in doc comments where appropriate
- Update README.md for significant feature additions

### Code Style

Follow Rust conventions:
- Run `cargo fmt` before committing
- Run `cargo clippy` and address warnings
- Use descriptive names for types and functions

### Constraints to Maintain

The library has specific design constraints that must be preserved:

1. **Zero runtime overhead** - System must remain a ZST
2. **Stable Rust only** - No nightly features
3. **cfg(test) only** - Verification code must not appear in release builds
4. **No DI opinion** - Dependencies type remains free
5. **static_assertions** - Must stay in dev-dependencies only

## Pull Request Process

1. Fork the repository
2. Create a feature branch (`git checkout -b feature/amazing-feature`)
3. Make your changes
4. Add tests for your changes
5. Ensure all tests pass (`cargo test --all`)
6. Ensure no warnings (`cargo build`)
7. Update documentation as needed
8. Commit your changes (`git commit -m 'Add amazing feature'`)
9. Push to your branch (`git push origin feature/amazing-feature`)
10. Open a Pull Request

## Pull Request Checklist

Before submitting a PR, ensure:

- [ ] All tests pass (`cargo test --all`)
- [ ] No build warnings (`cargo build`)
- [ ] Code is formatted (`cargo fmt`)
- [ ] Clippy is happy (`cargo clippy`)
- [ ] Documentation is updated
- [ ] Examples work if applicable
- [ ] VERIFICATION.md is updated if needed

## Reporting Issues

When reporting issues, please include:

1. Rust version (`rustc --version`)
2. Operating system
3. Minimal reproducible example
4. Expected vs actual behavior
5. Error messages or stack traces

## Feature Requests

Feature requests are welcome! Please:

1. Check existing issues first
2. Describe the use case clearly
3. Explain why it fits the library's goals
4. Consider submitting a PR if you can implement it

## Questions?

Feel free to open an issue for questions or discussions about:
- API design
- Use cases and examples
- Integration patterns
- Performance considerations

## License

By contributing, you agree that your contributions will be licensed under the MIT License.