Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

refactor: per-feature operation modules so features can land in parallel

Open
  • Is something wrong?
#78 6 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
12/100
Issue type
Refactor
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
desktop, developer-experience

Research direction

This is design work spanning src/app.rs, src/editor_operations.rs, src/mcp/tools.rs and src/mcp_editor_tests.rs, and it is meant to be planned and reviewed before any code. Start by reading move_ui.rs and move_mcp_tests.rs to see the per-feature pattern the issue wants to generalise, then the central dispatch in apply_operation_guarded. Done means a reviewed plan, not a patch; a newcomer should wait for maintainer direction.

Written by the indexing model from the issue text.

Description

area/infra area/mcp effort/m impact/internal in-progress priority/p2 severity/low triaged type/chore urgency/this-quarter

Problem

Every user-facing feature edits the same central files, so independent PRs always conflict and each rebase needs hand composition and re-review (Face, curves and Move all conflicted in these files on 2026-10-15/16):

File Role every feature touches
src/app.rs (~4.9k lines) editor state, guards, apply_operation_guarded, menus, shortcuts, panels, inspection, large test module
src/editor_operations.rs Operation enum and hardcoded TOOL_NAMES: [&str; N]
src/mcp/tools.rs central parse_request match, catalog, annotation list
src/mcp_editor_tests.rs (~4.8k lines) single protocol test file

Tool counts are also written as prose ("twenty-eight tools") in README, .project-docs/mcp.md and an app.rs assertion, so unrelated features conflict on docs.

Goal

A feature can be added mostly in its own module(s) with only small, append-only touches to shared dispatch, so external contributors and agents can work in parallel under the issue-claim and draft-PR workflow.

Proposed direction (to be planned and reviewed before code)

  1. Per-feature operation modules: each feature declares its typed operation(s), guard requirements, MCP tool schema and parser, inspection fragment and native UI hooks. move_ui.rs / move_mcp_tests.rs are the seed of this pattern.
  2. Derived catalog: TOOL_NAMES and the MCP catalog are built from registered features; docs reference a generated tool table instead of literal counts.
  3. Split app.rs (shell/layout, guards and dispatch, menus/shortcuts, panels) and mcp_editor_tests.rs (per feature).
  4. Contributor docs: area map and an "adding a feature" guide separated from verification evidence logs.

Acceptance

  • Behavior-neutral: every existing unit, Editor protocol, SDK and headless GPU test passes unchanged except for moves; MCP schemas byte-identical (snapshot test) unless a change is intended and reviewed.
  • Native UI and MCP still dispatch the same typed operations through the same guards (drafts/commit_pending, modal, close, dirty scene, scene token, Move busy).
  • A demonstration that adding a new tool touches only its module plus append-only registration.
  • Landed as a reviewed PR series, each PR atomic and CI green.

Sequenced after the Move PR (#77) and before Rotate/Scale (#34, #35, #36), which will be the first features built on it.

Dominant language
Rust
Stars
4
Forks
2
Avg merge
2h 51m
Merged PRs (30d)
84

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from cristim/AztecCraft

All issues in cristim/AztecCraft

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.