Generalize Move transactions into kind-based manipulation (Move/Rotate/Scale)
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
Research direction
Start from the current Move transaction code and MCP tool definitions that expose set_active_tool, begin_move, update_move and finish_move, plus their existing MCP tests. Read .project-docs/mcp.md and its coverage inventory to see where tool schemas and protocol tests are documented. The work is done when those Move-specific names become Manipulation* with a ManipulationKind enum, one tool per behavior, typed kind/parameter errors, synchronized schemas, and the same tests ported. Confirm the prerequisite Move landed and re-read merged hunks before starting.
Written by the indexing model from the issue text.
Description
Problem
The Move transaction and MCP tools are Move-specific; Rotate and Scale need shared guards.
Current behavior
World-axis Move (landing now) exposes set_active_tool, begin_move, update_move, finish_move.
Expected behavior
Rename MoveId/MoveError to Manipulation*, add a ManipulationKind enum, and replace *_move with begin_manipulation{kind,...}, update_manipulation, finish_manipulation in one atomic commit after every Move MCP test is ported. One tool per behavior, never two.
Acceptance criteria
- Schema uses oneOf with additionalProperties false; kind/parameter mismatch is a typed error.
- Prerequisite: Move landed on main and merged hunks re-read.
- Unimplemented controls stay visibly disabled with a reason; no dummy tools or controls.
- MCP coverage in the same change: implemented operations and relevant state exposed with synchronized tool schemas, real Editor protocol tests (scene token, draft, modal, close and busy guards) and updates to
.project-docs/mcp.mdand its coverage inventory. - Native visual check of the real window (screenshot reviewed), not only headless tests.
- Tests cover malformed, empty, boundary and failure cases; failed operations preserve the baseline.
- No parity claim without comparison against the pinned Maya reference (#5); unverified constants are documented as provisional.
- Dominant language
- Rust
- Stars
- 4
- Forks
- 2
- Avg merge
- 2h 28m
- Merged PRs (30d)
- 76
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from cristim/AztecCraft
-
area/viewport type/chore
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
cristim/AztecCraft#186 ·
Maintainers usually reply within 1 day
-
area/infra type/chore
Difficulty 1/5 Under an hour Newbie friendliness 94/100
cristim/AztecCraft#181 ·
Maintainers usually reply within 1 day
-
area/modeling type/bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
cristim/AztecCraft#176 ·
Maintainers usually reply within 1 day
-
area/modeling type/bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
cristim/AztecCraft#175 ·
Maintainers usually reply within 1 day
-
area/ui-parity type/bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
cristim/AztecCraft#172 · 1 comment ·
Maintainers usually reply within 1 day
All issues in cristim/AztecCraft
Similar issues
-
area:ecosystem documentation
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Chelis-Lang/chelis#3866 ·
Maintainers usually reply within 1 day
-
bug documentation sev-0
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
dekobon/big-code-analysis#1620 ·
Maintainers usually reply within 3 days
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 65/100