M.V. Hutz
1974ad582f
## Description This PR completes the MVC-inspired refactoring by moving the event system from the engine into the reducer. The engine package is now removed entirely, as the reducer handles both reduction logic and lifecycle events. - Add `pkg/reducer/events.go` with `StartEvent`, `StepEvent`, and `StopEvent`. - Extend `Reducer` interface to embed `Emitter[Event]` and add `Expression()` method. - Update `NormalOrderReducer` to embed `BaseEmitter` and emit lifecycle events during reduction. - Update all plugins to attach to `Reducer` instead of `Engine`. - Remove `internal/engine` package entirely. - Add `Off()` method to `BaseEmitter` to complete the `Emitter` interface. - Fix `Emitter.On` signature to use generic type `E` instead of `string`. ### Decisions - The `Reducer` interface now combines reduction logic with event emission, making it the single orchestration point. - Plugins attach directly to the reducer, simplifying the architecture. - The `Expression()` method on `Reducer` provides access to current state for plugins. ## Benefits - Simpler architecture with one fewer abstraction layer. - Plugins are now mode-agnostic - they work with any `Reducer` implementation. - Cleaner separation: reducers handle reduction, plugins observe via events. - Easier to add new evaluation modes - just implement `Reducer` with embedded emitter. ## Checklist - [x] Code follows conventional commit format. - [x] Branch follows naming convention (`<type>/<description>`). - [x] Tests pass (if applicable). - [ ] Documentation updated (if applicable). Reviewed-on: #32 Co-authored-by: M.V. Hutz <git@maximhutz.me> Co-committed-by: M.V. Hutz <git@maximhutz.me>
106 lines
3.0 KiB
Markdown
106 lines
3.0 KiB
Markdown
# Guide To `lambda`
|
|
|
|
## Documentation Style
|
|
|
|
Use full sentences.
|
|
Every sentence gets its own line in Markdown.
|
|
Every sentence ends in a period.
|
|
|
|
## Coding Style
|
|
|
|
### Conventional Commits
|
|
|
|
Use conventional commit format: `<type>: <description>`.
|
|
|
|
**Types**: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`, `perf`
|
|
|
|
**Examples**:
|
|
|
|
- `feat: add explanation mode flag to CLI`
|
|
- `fix: correct variable renaming in nested abstractions`
|
|
- `docs: update Makefile documentation`
|
|
|
|
DO NOT advertise Claude.
|
|
|
|
### Branch Names
|
|
|
|
Use format: `<type>/<description>` with kebab-case.
|
|
|
|
**Types**: Same as commits: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`, `perf`.
|
|
|
|
**Examples**:
|
|
|
|
- `feat/explanation-mode`
|
|
- `fix/variable-renaming`
|
|
- `docs/makefile-improvements`
|
|
- `refactor/silent-directive`
|
|
|
|
DO NOT advertise Claude.
|
|
|
|
## Issue Management
|
|
|
|
Use the `tea` CLI (Gitea command-line tool) for issue operations.
|
|
|
|
**Common commands**:
|
|
|
|
- `tea issues list` - List all issues.
|
|
- `tea issues <number>` - View details of a specific issue.
|
|
- `tea issues create --title "<title>" --body "<description>"` - Create a new issue.
|
|
- `tea issues close <number>` - Close an issue.
|
|
|
|
**Reading issues**: Use `tea issues <number>` to read the full details of an issue before starting work.
|
|
|
|
## Issue Workflow
|
|
|
|
When working on an issue:
|
|
|
|
1. Read the issue using `tea issues <number>` to understand requirements.
|
|
2. Create a feature branch following the branch naming convention.
|
|
3. Make commits following the conventional commit format.
|
|
4. Submit a pull request when ready.
|
|
|
|
**Important**: Never commit directly to `main`.
|
|
All work must be done in a feature branch and submitted via pull request.
|
|
|
|
## Pull Request Management
|
|
|
|
Use the `tea` CLI (Gitea command-line tool) for PR operations instead of `gh`.
|
|
|
|
**Common commands**:
|
|
|
|
- `tea pr create --title "<title>" --description "<body>"` - Create a new pull request.
|
|
- `tea pr list` - List pull requests.
|
|
- `tea pr checkout <number>` - Check out a PR locally.
|
|
- `tea pr close <number>` - Close a pull request.
|
|
- `tea pr merge <number>` - Merge a pull request.
|
|
|
|
**Note**: Use `--description` (not `--body`) for PR body content.
|
|
|
|
**Creating PRs**: Always create PRs in a branch other than `main`, to the `main` branch unless specified otherwise. ALWAYS FOLLOW THE PR TEMPLATE, EXACTLY.
|
|
|
|
**Linking issues**: When a PR solves an issue, reference the issue in both the commit message and PR description using `Closes #<number>`.
|
|
This automatically links and closes the issue when the PR is merged.
|
|
|
|
### Updating PRs
|
|
|
|
When pushing additional changes to an existing PR, add a comment summarizing the new commits.
|
|
This keeps reviewers informed of what changed since the initial PR description.
|
|
|
|
Use the `tea` CLI to add comments to pull requests:
|
|
|
|
```bash
|
|
tea comment <number> "Comment text"
|
|
```
|
|
|
|
#### Examples
|
|
|
|
```bash
|
|
# Add a comment to PR #42
|
|
tea comment 42 "Updated implementation based on feedback"
|
|
|
|
# Add a multi-line comment
|
|
tea comment 42 "Summary of changes:
|
|
- Fixed bug in reducer
|
|
- Added new tests"
|
|
```
|