task-decomposition

Task Decomposition

Overview

After the plan is written and self-reviewed, turn it into implementation board tasks with create_board_task. Decomposition quality decides whether developers can work in parallel without stepping on each other.

Slicing Rules

• One repository + one layer per task (backend / frontend / mobile / data / game). Never bundle layers — a task that says "add the API and the UI" is two tasks, and so is "train the model and serve it from the API" when the serving endpoint lives in a backend service.
• Each task maps to one or more plan tasks that form an independently deliverable unit: its tests can pass and its code can be reviewed without waiting for a sibling.
• Order by dependency: backend API before the frontend/mobile that consumes it. Declare it in the ARGUMENTS (see "Ordering is an argument" below), and write the human-readable "Depends on: — consumes POST /api/v1/..." line in the description as well — but never only the line, because prose enforces nothing.
• A project with UI and no design system: call get_design_system (with the project's project_id) before slicing UI work. If it returns no base — and the UI repository no layer — never hand-write a design task for it: call request_design_system (scope: "project" with the project_id; scope: "repository" with its repository_id for a UI repository in no project), with what the analysis knows about the audience, the feel and the brief's references in notes. It opens the same design task the project's Design System tab opens — the ui-designer assigned, the server's brief as its description — or returns the one already open (created: false); its returned key is what every UI task and every screen design task below waits for with blocked_by (it lives in one UI repository; a blocker in another repository is fine). On approval the designer opens an "Apply design system vN" task per repository that writes the generated design files and builds the foundation (tokens, atomic folders + INVENTORY.md, base atoms, ui-guard) from them — so do not also create a separate "Add design system foundation" task. The UI tasks in one repository are chained with blocked_by (shared files serialize, below); the first one writes the generated files from get_design_system files: true verbatim before its screen — the same bytes the Apply task writes.
• Design first for a screen nobody has designed: a frontend or mobile task whose screen has no approved design (no design task already covers it) and no matching existing screen to follow gets a screen design task first — create_board_task with task_type: "design", no assignee, repository (the repository the screen ships in), derived_from this analiz task, a description naming the screen(s), the audience and the states the plan needs, and blocked_by the design-system task when you requested one above (a screen is drawn only with an approved design system). The frontend/mobile tasks for that screen are blocked_by the screen design task — that alone hands their runs its approved mockups and hand-off spec, and they start only once the designer has written the hand-off and released it; their derived_from stays this analiz task. A change that follows an existing screen's pattern needs no design task.
• Size: a task should land at an estimated ≤ ~400 changed lines including tests, so a reviewer sees the whole diff inside the 24,000-byte cut (review-reads-whole-diff); over ~1,000 is a split. Keep refactors in their own task, separate from feature work.
• Shared files serialize: two tasks in one repository that both add a migration (sequence numbers collide), or edit the same router table, locale bundle, DI container, INVENTORY.md or OpenAPI file, are chained with blocked_by rather than left to collide at review time.