Skip to content

Route mill/bakery ticks through BuildingCapability, key conversion st… - #734

Merged
gaidheal1 merged 1 commit into
developmentfrom
feat/building_capabilities_tasks
Aug 9, 2026
Merged

Route mill/bakery ticks through BuildingCapability, key conversion st…#734
gaidheal1 merged 1 commit into
developmentfrom
feat/building_capabilities_tasks

Conversation

@gaidheal1

Copy link
Copy Markdown
Member

…ate by activity

advance_mill_economy_tick/advance_bakery_economy_tick now iterate buildings by capabilities__activity instead of building_type, so a building with multiple capabilities (e.g. a communal building that both mills and bakes) gets ticked for each one.

GoodsConversionState moves from a per-building OneToOneField to a per-(building, activity) ForeignKey + unique constraint, with a backfill migration mapping existing rows by their building's building_type. This is required alongside the tick change: with a single per-building flag, the first tick to run today would mark the building "processed" and the second would silently skip - see .claude/plans/building-capabilities-plan.md's Edge Cases. Added a regression test (MultiCapabilityBuildingTests) covering exactly this: a communal building with both capabilities produces bread on the same day, which is only possible if both ticks ran.

economy_status now prints every conversion state on a building instead of assuming one. Step 3 of the plan.

Claude-Session: https://claude.ai/code/session_01LxvVvCwZw9HrxFcspgbmSK

Base automatically changed from feat/building_capabilities to development August 9, 2026 17:37
@gaidheal1
gaidheal1 force-pushed the feat/building_capabilities_tasks branch from 5d3b06a to 2af31f6 Compare August 9, 2026 17:37
…ate by activity

advance_mill_economy_tick/advance_bakery_economy_tick now iterate
buildings by capabilities__activity instead of building_type, so a
building with multiple capabilities (e.g. a communal building that both
mills and bakes) gets ticked for each one.

GoodsConversionState moves from a per-building OneToOneField to a
per-(building, activity) ForeignKey + unique constraint, with a backfill
migration mapping existing rows by their building's building_type. This
is required alongside the tick change: with a single per-building flag,
the first tick to run today would mark the building "processed" and the
second would silently skip - see .claude/plans/building-capabilities-plan.md's
Edge Cases. Added a regression test (MultiCapabilityBuildingTests)
covering exactly this: a communal building with both capabilities
produces bread on the same day, which is only possible if both ticks ran.

economy_status now prints every conversion state on a building instead of
assuming one. Step 3 of the plan.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LxvVvCwZw9HrxFcspgbmSK
@gaidheal1
gaidheal1 force-pushed the feat/building_capabilities_tasks branch from 2af31f6 to 0c6f02f Compare August 9, 2026 17:51
@gaidheal1
gaidheal1 merged commit b312f48 into development Aug 9, 2026
2 checks passed
@gaidheal1
gaidheal1 deleted the feat/building_capabilities_tasks branch August 9, 2026 17:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant