[P3] Rotating "build X" goals complete on foundation placement, not structure completion

[itsmiso-ai]

Ask: Make the rotating "build X" goals require a completed structure to count progress, matching the same-named milestone, instead of completing the moment a foundation is placed.
Expected files: scripts/rotating_goal.gd, tests/test_goal_progression.gd

Problem:
RotatingGoal.compute_build_progress counts a build toward the build_hut/build_workshop/build_garden goals whenever build.kind or build.build_kind equals the target kind, with no check on build.complete. Because a build object is created with "kind": "hut" the instant the foundation is queued (see queue_structure_at), current_progress becomes non-zero immediately on placement, and since is_goal_complete for GOAL_TYPE_BUILD only requires current_progress > 0, the goal now completes and grants its reward (e.g. the +1 food trickle) as soon as the player places the foundation — before any materials are hauled or the structure is actually finished. This is inconsistent with the same-named milestone: MilestoneManager.evaluate_milestone for MILESTONE_TYPE_BUILD explicitly requires bool(build.get("complete")), so the milestone and the rotating goal disagree on when "Build a hut" is achieved. The player sees the garage reward fire early and the milestone still pending, a confusing discrepancy in the core progression loop.

Evidence:

• scripts/rotating_goal.gd compute_build_progress — counts build.get("kind", "") == target_kind or build.get("build_kind", "") == target_kind with no complete check
• scripts/rotating_goal.gd is_goal_complete — GOAL_TYPE_BUILD returns current_progress > 0
• scripts/main.gd queue_structure_at (≈line 1285) — creates the build with "kind": kind and "complete": false at placement
• scripts/milestone_manager.gd evaluate_milestone MILESTONE_TYPE_BUILD — guards on bool(build.get("complete")), the contrasting behavior
• tests/test_goal_progression.gd _test_compute_build_progress — current test asserts progress counts builds without a complete field, codifying the placement-based behavior

Acceptance:

• After placing a foundation for a hut (build not yet complete), the build_hut rotating goal does not complete.
• The build_hut goal completes only once a matching structure is complete: true.
• tests/test_goal_progression.gd is updated to include an incomplete build that does not count and a completed one that does.

[itsmiso-ai]

Not worth doing yet

Considered but deliberately not filed as separate issues this audit (beyond #345/346/347/348/349):

• reserve_resource() does not mark_dirty() (scripts/colony_sim.gd). It mutates the persisted reserved_resources map while the symmetric release_resource() does mark dirty. In practice reservations self-heal because they are force-rebuilt on load (sim.rebuild_reservations()), and a reservation is almost always followed by a gather/haul that marks dirty, so no observable data loss. Revisit only if reservation persistence must survive a mid-walk save boundary.

• Worker movement / tick counter not marked dirty on quiet walking ticks. step_worker moves worker.pos without mark_dirty(), and process_tick increments tick directly, so a quiet tick (a worker merely walking) can be skipped by the debounced persist(). Self-healing on reload (positions re-walk, reservations rebuild) and low practical impact; the dirty-tracking test (test_dirty_state_tracking.gd) already covers the intent.

• Out-of-bounds worker/build positions in a schema-valid save. Considered as a crash path, but main.gd:is_save_compatible (run on both desktop and web load via load_game → is_save_compatible) bounds-checks every worker and build pos, and step_toward walks out-of-bound workers back to valid targets. Not an actionable gap.

• Web save_game/load_game ignore the path argument (scripts/game_state.gd). Latent API inconsistency but no caller passes a path on a web build; same conclusion as the prior audit — revisit only if a named/multi-save feature arrives.

• Dependencies/security. No injection/new findings. Godot toolchain pinned to 4.7.1 with SHA-256 checksums, CI actions pinned by commit SHA, and renovate.json extends the shared misospace/renovate-config. localStorage XSS and schema-validation hardening already landed ([P2] Web localStorage load path skips save-schema validation and migration #313, [P3] No Web export preset or CI coverage for the localStorage/JavaScriptBridge persistence path #316, Fix #329: Validate reserved_resources, milestone, and build-id fields in save schema #336).