spae-build

Build

When to use

• STATE.json has phase: build.
• The work stream needs the next planned task completed.

Goal

• Execute exactly one task from PLAN.md, mutating source/tests plus STATE.json, while preserving the framework execution cursor.
• Complete the active task with minimal production code that meets exhaustive tests, serves its Intent and the plan ## Goal, and leaves seams for downstream tasks.
• Meet the task acceptance criteria through exhaustive tests and task verification steps.
• Hand off to /check for the done transition and cursor advance; never claim either.

Input

Read:

• .spae/current/STATE.json for phase, cursor, and task registry (consult references/STATE.md for field reference, directives, and phase snapshots).
• .spae/current/PLAN.md for the plan ## Goal, the active task, its Intent, acceptance criteria, and verification steps; they carry all the goal context build needs.
• Relevant project source, tests, docs, and configuration needed for the active task.

Testing

See references/testing-guide.md for test structure, isolation, mocking, assertion, and performance standards.

Cleanup

See references/cleanup-guide.md for the self-introduced-artifact checklist and diff-only audit scope.

Workflow

1. GATE—Confirm .spae/current/STATE.json has phase: build and an active task. Halt on state drift: if tasks[active_task_id] reads "done", halt; report and make no changes. Read the plan ## Goal and active task section — including its Intent — from .spae/current/PLAN.md. Read dependent and forward task titles plus acceptance criteria to map seams, not build them. Verify every task ID in the active task's Dependencies field carries status "done" in tasks registry in STATE.json; fail the task for any incomplete dependency.
2. ORIENT—State the goal in one sentence: execute the active task and hand off to /check. Name what won't change: PLAN.md, SPEC.md, and forward-task seams. Task status update: set tasks[active_task_id] to "in_progress" in .spae/current/STATE.json.
3. PLAN—Declare the full implementation path that satisfies every acceptance criterion, advances the task Intent and plan ## Goal, and leaves seams for forward tasks. Read references/testing-guide.md, references/shell-command-guide.md, and references/cleanup-guide.md. Map the test surface per criterion: expected behaviors, failure modes, and edge cases. Choose among valid implementations by goal fit, not local convenience.
4. ACT—Iterate over every acceptance criterion:
   • Write a failing test: expected behavior, failure modes, and edge cases.
   • Write minimal code to pass it.
   • Drive green; repeat test→implement until the criterion passes.