Files

M.V. Hutz 1974ad582f refactor: move event system to reducer, remove engine package (#32 )

## 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>

2026-01-17 00:27:36 +00:00

3.0 KiB

Raw Blame History

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:

Read the issue using tea issues <number> to understand requirements.
Create a feature branch following the branch naming convention.
Make commits following the conventional commit format.
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:

tea comment <number> "Comment text"

Examples

# 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"

3.0 KiB Raw Blame History

Guide To lambda